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@ Integrated trading provides both automatic 
matching trades for trading instruments between po- 
tential counterparties and video conversational nego- 
tiated trades for trading instruments between poten- 
tial counterparties using integrated keystations (202, 
204, 206. 208) which are selectively connectable 
together. Each of the keystations (202, 204. 206, 
208) includes a data input device, such as a key- 
board (240) and a mouse (242). and an integrated 
screen display (238), with the keyboard (240) and 
the display (238) being shared for both the automatic 
matching trades effectuated by the keystation (202, 
204, 206. 208) through a matching network (220) and 
the video conversational negotiated trades keystation 
(202. 204, 206, 208) through a separate conversation 
network (218). An integrated terminal controller (214, 
216) is provided as a common interface between the 
keystations (202, 204. 206. 208) and the separate 
networks (218. 220). Transaction data is provided 
between given keystations (202. 204. 206. 208) in 



the. system (200) relating to both automatic matching 
transactions and video conversational negotiated 
trading transactions through the common integrated 
terminal controller (214, 216) which interfaces with 
the separate communication paths associated with 
the automatic matching trades (220) and the video 
conversational negotiated trades (218) effectuated by 
the keystation (202, 204. 206, 208). The integrated 
terminal controller(214, 216) comprises a conversa- 
tion server (252), a concentrator computer (254), the 
terminal computers (250) associated with the various 
keystations (202. 204, 206, 208) it serves, and a 
local area network (256) tieing them together. Initial 
access to both types of trades can be obtained at 
log on. A common ticket generation scheme for both 
types, of trades is used so that trading tickets may 
be collected and communicated to a remote back 
office data base through the integrated terminal con- 
troller (214, 216), via the conversation server (252), 
irrespective of the type of trade completed. 
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INTEGRATED TRADING 



The present invention relates to effectuating 
trades of trading instruments both through auto- 
matic matching, in which buyers and sellers who 
are willing to trade with one another based on 
specified criteria may automatically trade when 
matching events occur satisfying these criteria, and 
through video converstaional negotiated trades, in 
which buyers and sellers who are willing to trade 
with one another may do so through exchanging 
video conversational textual messages, and are 
particularly to the methodology of integrating these 
different types of trades in a system which enables 
individual keystations to accomplish both types of 
trades. 

Information retrieval systems for financial in- 
formation, such as stock market type of information 
and money market information, normally employ a 
transfer "of data in a high performance, real time 
information retrieval network in which update rates, 
retrieval rates and subscriber and/or user popula- 
tion are generally very high. An example of such a 
system is REUTERS DEALING SERVICE, which is 
used in the foreign exchange market, or GLOBEX. 
which is used by the Chicago Mercantile Exchange 
for electronic trading in the commodities market. 
Such systems, while providing rapid communica- 
tion capability between subscribers, have been pre- 
viously dedicated to one type of trading capability, 
albeit video conversation capability to effectuate 
negotiated trades through textual messages ex- 
changed between potential counterparties, such as 
in DEALING, or automatic matching capability to 
automatically effectuate trades between anony- 
mous potential counterparties meeting certain user 
specified criteria, such as in GLOBEX. Each of 
these types of systems have their place in the 
market and serve particular needs where appro- 
priate. However, because of world of trading of 
financial instruments and the requisite needs asso- 
ciated therewith are dynamic and rapidly change 
with changes in the surrounding circumstances, at 
one moment it may be desirable to trade anony- 
mously in an automatic matching environment 
while at the very next moment it may be desirable 
to openly trade in a video conversational negotiat- 
ing environment, or to do both, for the same or 
different trading instruments. Thus, although there 
have been successful trading systems doing one of 
these types of trades, there are no known prior art 
systems which effectively integrate both of these 
types of trades in a single system so as to permit a 
trader, using a single keyboard and display screen, 
to selectively switch between the two types of 
trading systems dependent on his own desires and 
needs at any given time in the trading environment. 



This is so despite the known technique in the prior 
art of tying common keyboard, such as described 
in US-A-4,404,551. in which a common keyboard is 
used to both communicate with multiple computer 
5 systems and multiplex or dynamically route or se- 
lect video displays on one or more VDUs from a 
plurality of simultaneously provided composite vid- 
eo signal inputs from these multiple computer sys- 
tems in response to unique keyboard generated 
10 character codes. 

In addition, despite known prior art systems 
which have attempted to integrate voice and data, 
such as disclosed in US-A-4,612,416; 4.598,367; 
4,653,045; 4,475,189; 3,344,401; and 4,635.251, 
75 none of these prior art systems, has integrated 
conversational trading, to enable negotiated trades, 
with automatic matching trades; to enable anony- 
mously matched trades, in a shared environment. 
For example, the system disclosed in US-A-4, 
20 598,367 is a financial quotation system employing 
a keypad input and a synthesized speech output, 
but does not integrate different types of trading 
transactions in a shared environment. Similarly, 
US-A-4, 509.167; 4.612,416; and 4.635.251, which 
25 are not directed to financial . information per se, 
merely disclose systems which integrate voice mail 
in a telephone communication system. US-A- 
4,653,045 and 4.475,189 also disclose telephone 
systems which integrate voice and data, with these 
30 systems being used in telephone conferencing. 
US-A-3.344,401 . discloses another type of tele- 
phone system in which voice is integrated with 
teletype for communicating with a remote data 
processor in an inquiry system; however, the dis- 
35 closed system is not utilized in a dynamic trading 
environment, such as one involving matching trans- 
actions and/or video conversational negotiated 
trades. 

Moreover, automatic matching trading systems 
40 are well known, such as described in US-A- 
3.573,747; 3,581.072; 4,412,287; 4.677.552; and 
4,674.044, as well as in EP-A-90305753; 0,399.850; 
90305763; and GB-A-2,227.625; 2,226,217; and 
2,224.141. However, although these prior art auto- 
46 matic matching systems are capable of automati- 
cally matching bids and offers, and may employ a 
central or host computer to accomplish this, such 
as disclosed in US-A-4.677.552; 4,674,044; and 
3,573,747; by way of example, they are incapable 
50 of enabling video conversational negotiated trades 
to also occur, thereby requiring a totally different 
system to be employed if the trader desires to then 
execute such a trade. This can provide significant 
trading disadvantages to the trader. 

In addition, although the REUTERS DEALING 
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SERVICE, enables multiple conversations to be 
carried out by a given subscriber in real tinne and 
in association with data base retrieval of supple- 
mentary data, such as described in US-A-4.531 ,184 
and 4,525.779, by way of example, as well as in 
the aforementioned EP and GB specifications relat- 
ing to video conversational trading systems, none 
of these systems integrates an automatic matching 
trading system with one capable of providing video 
conversational negotiated trades. 

Apart from the. above, there are no known 
trading systems of this type in which a keep alive 
signal is periodically provided to the system in 
order to notify the system that a given subscriber 
keystation is operating properly so that , all out- 
standing active bids and offers associated with the 
keystation can be automatically deleted from the 
trading system if the keystation fails or is unable to 
provide the periodic keep alive signal to the sys- 
tem. This enables a trader who becomes mechani- 
cally locked out from active trading by keystation 
failure to be automatically removed from the trad- 
ing base so as to ensure that completed trades are 
accomplished only between active traders who are 
able to participate in the trading transactions which 
are occurring, whether they are anonymous trades 
or negotiated trades. 

Another feature lacking in the known prior art 
relates to the provision of a high speed, reliable 
system for providing a common ticket generation 
scheme for providing trading ticket information to a 
back office computer without continual polling, ir- 
respective of the type of deal or trade which has 
occurred. Although reliable ticket generation 
schemes are known, such as described in the 
above aforementioned EP and GB specifications 
relating thereto, and although methods and sys- 
tems for dynamically controlling the content of a 
local receiver data base from a transmitted data 
base in an information retrieval communication net- 
work for collecting financial information are also 
known, such as described in US-A-4,745,559, no 
prior art systems are known which provide com- 
mon ticket generation for automatic matching 
trades and for video converational negotiated 
trades, nor are any such prior art systems known in 
which both types of completed trades may be 
stored together for retrieval. 

Thus, there are no known prior art systems or 
methods which can readily combine the advan- 
tages, speed and reliability of both automatic 
matching and negotiated video conversational 
trades in a single system so as to provide the 
individual subscribers or keystations with maximum 
flexibility and optimal efficiency to effectuate the 
type of trade demanded by the time and circum- 
stances available. These disadvantages of the prior 
art are overcome by the method of the present 



invention. 

The present invention is set out in its various 
aspects in the independent claims of the present 
application. 

5 An example of the invention will now be de- 

scribed with reference to the accompanying draw- 
ings in which: 

Fig 1 is an overall system functional block dia- 
gram of a system capable of carrying out an 

10 integrated trading method; 

Fig 2 is a functional block diagram of a typical 
client site in the system of Fig. 1, illustrating a 
typical preferred integrated terminal controller; 
Fig 3 is a functional block diagram similar to 

75 Fig. 2, illustrating the portion of the presently, 
preferred integrated terminal controller relating 
to the carrying out of video conversational nego- 
tiated trades; 

Fig 4 is a diagramatic illustration of. a typical 
20 communication network for carrying out video 

conversational negotiated trades; 

Fig 5 is a diagramatic illustration of a typical 

terminal computer associated with a typical 

keystation in the system of Fig. 1 ; 
25 Fig 6 is a diagramatic illustration, similar to Fig. 

5. of a typical conversation server portion of the 

presently preferred integrated terminal controller 

of Rg. 2; 

Fig 7 is a functional block diagram, similar to 
30 Fig, 4, illustrating the network associated with 
carrying out automatic matching trades in the 
system of Fig. 1; 

Fig 8 is a functional block diagram of the net- 
work of Fig. 7 illustrating the flow of information 

35 in connection with the entry of a bid-and the 
entry of an offer in connection with effectuating 
automatic matching trades between potential 
counterparties in the system of Fig. 1; 
Fig 9 is a functional block diagram similar to 

40 Fig. 8. of the flow of information in the network 
of Fig. 7 in connection with a hit bid or trade in 
connection with the carrying out of automatic 
matching trades between potential counterpar- 
ties in the system of Fig. 1; 

45 Fig 10 is a diagramatic illustration of a typical 
integrated video screen display for a typical 
integrated keystation in the system of Fig. 1 
when the small font option has been selected; 
Fig 11 is a diagramatic illustration, similar to Fig. 

50 10, of a typical integrated video display screen 
layout when matching has been selected by the 
integrated keystation in Fig.1; 
Fig 12 is a diagramatic illustration, similar to Fig. 
10, of the video screen layout of Fig. 11 when 

55 the video conversational trade option has been 
selected with the display of Fig. 12 toggling with, 
the display of Fig. 11; 

Fig 13 is a diagramatic illustration similar to Fig. 
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10 of a typical integrated video screen display 
for a typical integrated keystation in the system 
of Fig. 1 when the large font option has been 
selected and the matching trade option has 
been selected; 5 
Fig 14 is a diagramatic illustration simitar to Fig. 
13, of a large font option for a typical integrated 
video screen display of a typical integrated 
keystation in the system of Fig. 1 when the 
video conversational trade option has been se- w 
lected, with the screen of Fig. 14 toggling with 
the screen of Rg. 13; 

Fig 15 is a diagramatic illustration of a typical 
integrated keyboard associated with a typical 
integrated keystation in the system of Fig. 1 ; ?5 
Fig 16 is an illustration of a typical matching 
ticket produced as a result of a matching trade 
in the system of Fig. 1; 

Fig 17 is a diagramatic illustration, similar to Fig. 
16/ of a typical conversation ticket produced in 20 
response to the completion of video conversa- 
tional negotiated trade in the system of Fig. 1 ; 
Fig 18 is a diagramatic state diagram of the 
sequence of operations associated with log on 
and log off a typical integrated keystation in the 25 
system of Fig. 1; 

Figs 19-20 compriise a logic flow diagram of the 
log on/log off sequence of operations illustrated 
in the state diagram of Fig. 18; 

Figs 21-24 are diagramatic illustrations of typical 30 
integrated video screen displays for a typical 
integrated keystation in the system of Fig. 1, 
illustrating the integrated trading capabilities of 
the system of Fig. 1, with Fig, 21 illustrating a 
typical integrated video display in which both 35 
information relating to automatic matching 
trades and information relating to video con- 
versational negotiated trades is present on the 
screen, but no trade has occurred with that 
keystation, with Fig 22 illustrating the screen of 40 
Fig. 21 with information about to be transmitted 
in connection with completion of a matching 
transaction, with Fig. 23 illustrating the automatic 
matching trade represented in Fig. 21 as having 
been executed and match notification having 45 
been received by the keystation, and with Fig 24 
illustrating the integrated display screen of Fig. 
21 when a video conversation negotiated trade 
has been completed; 

Fig 25 is a logic flow diagram of the operation of so 
a typical integrated keystation in the system of 
Fig. 1 in response to receipt of a match notifica- 
tion signal; 

Fig 26 is a logic flow diagram, similar to Fig. 25, 
of the operation of a typical integrated keysta- 55 
tion in the system of Fig. 1 in response to 
receipt of a match ticket or conversation ticket; 
Figs 27-29 are logic flow diagrams, similar to 



Fig. 25, illustrating the operation of a typical 
integrated keystation in the system of Fig. 1 with 
respect to the keep alive feature, with Rg. 27 
illustrating the operation of the integrated key- 
board, and Figs. 28 and 29 illustrating the op- 
eration of the terminal computer portion of the 
integrated keystation; 

Fig 30 is a functional block diagram illustrating 
the flow of information in connection with a 
typical matching transaction: 
Fig 31 is a diagramatic illustration of a portion of 
the trading ticket output process utilizable in the 
system of Fig. 1 concerned with the ticket out- 
put protocol; 

Fig 32 is a logic flow diagram of a ticket output 
process; 

Rg 33 is a logic flow diagram of the operation of 
the integrated terminal controller when a new 
trading ticket has been generated in accordance 
with the trading ticket output process of Rg. 32; 
Fig 34 is a logic flow diagram of the operation of 
the database server portion of the integrated 
terminal controller in the system of Fig. 1 with 
respect to requests for tickets received by the 
database server from a back office computer; 
Fig 35 is a logic flow diagram of the data 
display application for initiating a fast conversa- 
tional contact message using the screen pointer 
in a typical integrated keystation in the system 
of Fig. 1; and 

Fig 36 is a logic flow diagram of the conversa- 
tion application processing of a fast conversa- 
tional contact message initiated in accordance 
with Fig. 35 for expanding the contact message 
and establishing conversational contact in the 
system of Fig. 1 . 
An integrated trading system 200. as will be 
described in greater detail hereinafter, is capable of 
effecting trades of trading instruments both through 
automatic matching, in which buyers and sellers 
who are willing to trade with one another based on 
specified criteria may automatically trade when 
matching events occur satisfying these criteria, and 
through video conversational negotiated trades, in 
which buyers and sellers who are willing to trade 
with one antoher may do so through exchanging 
video conversational textual messages. Individual 
integrated keystations, with four such integrated 
keystations 202, 204, 206 and 208 being shown by 
way of example in Fig. 1. are able to accomplish 
both types of trades. In addition, as will be de- 
scribed in greater detail hereinafter individual 
keystations which are only capable of performing 
one of these types of trades can trade with another 
keystation of that type or with an integrated keysta- 
tion which is capable of performing both types of 
trades. In this regard, as shown and preferred in 
Figs. 1 and 2, an integrated terminal controller with 
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two such client sites 210, 212 being illustrated by 
way of example, in Fig. 1. One such integrated 
terminal controller 214, 216 is Illustrated at each 
client site 210, 212, respectively, by way of exam- 
ple, in Fig. 1 . 

As shown and preferred in Figs. 1 and 2, a 
typical integrated terminal controller 214, may ac- 
commodate a plurality of integrated keystations 
202, 204, by way of example, and is the system 
interface for these keystations 202. 204 with the 
other keystations 206, 208 in the system 200 in 
order to enable the different types of trades to be 
effected with these integrated keystations 202. 204. 
206, 208. As shown by way of example in Fig. 1. 
each type of trade, namely video converstational 
negotiated trades and automatic matching trades, 
has its own associated communication network 
218. 220 respectively, since the population of in- 
dividual subscribers involved in automatic matching 
trades. In this regard, there is a host computer 222 
associated with the routing of conversational trade 
and there is a separate matching host computer 
224 which is actually responsible for the matching 
trades which occur through the matching commu- 
nication network 220, such as described in greater 
detail in the above European publications. Suffice it 
to say that the present control and operation of 
automatic matching trades is preferably the same 
as described in these EP and GB specifications, 
with the exception of the involvement of the in- 
tegrated terminal controller 214, 216, with reference 
to a typical terminal controller 214 to be described 
in greater detail hereinafter, and . the use of the 
integrated keystation 202, 204. 206, 208 with the 
operation of a typical integrated keystation 202 to 
be described in greater detail hereinafter. 

A common ticket generation scheme and ticket 
output feed to the back office computer is used for 
both the video conversational negotiated trades 
performed by the system 200 and the automatic 
matching trades performed by the system 200. 
Similarly, with respect to the video conversational 
negotiated trades performed by the system 200, 
these trades are preferably performed in the same 
manner as described in GB-A-2,226.217 and GB-A- 
2,227.625. with the exception, once again of the 
involvement of the integrated terminal controller 
214. 216 and the integrated keystations 202, 204, 
206. 208. which enables both this type of trade and 
the automatic matching trades to be integrated in 
the same system 200 and provided on a common 
video display 238, and which provides a common 
ticket generation scheme for both types of trades. 
With respect to the common ticket generation 
scheme, except for the differences to be described 
hereinafter, the ticket generation in the system 200, 
which also describes the provision of the ticket 
output fee to the back office computer. 



As shown in Fig. 1. each of the integrated 
terminal controllers 214. 216. has an associated 
ticket printer 226. 228 respectively, and an asso- 
ciated conversation printer 230. 232, respectively. 

5 as well as a ticket output feed 234, 236. respec- 
tively, to its associated back office computer. With 
respect to the individual integrated keystations 202, 
204, 206. 208 to be described in greater detail 
hereinafter, a typical integrated keystation 202 pref- 

70 erably has an integrated screen display 238. to be 
described in greater detail hereinafter and illus- 
trated by way of example, in Figs. 10-14 and Figs. 
21-24, an integrated keyboard 240. such as the 
typical keyboard illustrated in Fig. 15. and a con- 

75 versational mouse 242 which may preferably be 
used to accomplish fast conversational contact, by 
way of example, such as in the manner described 
in GB-A-2,227,625, and illustrated, by way of exam- 
ple in Figs. 35-36 which correspond to Figs. 11-12 

20 of GB-A-2,227.625. 

As shown in Fig. 2. the integrated terminal 
controller 214 comprises a terminal computer 250 
associated with each keystation. The terminal com- 
puter 250 is preferably a conventional computer 

25 configuration, such as an 80386 Intel 302 computer 
for each integrated keystation 202, 204, 206, 208. 
In addition, the integrated terminal controller 214 
also preferably includes a conversation server com- 
puter 252, such as one comprising another 80386 

30 Intel 302 computer, and which is shown in greater 
detail in Fig. 3. and a concentrator computer 254, 
such as a MICRO VAX 2000 computer, for commu- 
nicating with the matching host computer 224 
through the matching communication network 220. 

35 The conversation server 252, the concentrator 
computer 254, and the terminal computers 250 
associated with the various integrated keystations 
202, 204, for example, are all preferably tied to- 
gether through a conventional local area network . 

40 256. such as an Ethernet network, with the con- 
centrator computer 254 preferably communicating 
with the conversation server 252 via the keystation 
terminal computer 250 connected to the local area 
network 256. As shown and preferred in Figs. 2 

45 and 3, and as will be described in greater detail 
hereinafter, the conversation server 252, which is 
shown in greater detail in Fig. 6, not only handles 
video conversational trading, but preferably ties 
together, in the integrated system 200, the printing . 

50 and ticket generation for both automatic matching 
trades and video conversational negotiated trades 
performed by a given integrated keystation 202, 
204 associated with that integrated terminal controlr 
ler 214, and is the interface with the associated 

55 back office computer for the ticket output feed for 
trades performed at that client site 210. irrespective 
of the type of trade performed. 

As shown and preferred in Fig. 3, although the 
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conversation server 252 is represented by only one 
block in Fig. 2, in reality it may be comprised of a 
line server 264 which enables, for example, the 
provision of context sensitive prompts during con- 
versational trading, such as described in greater 
detail in GB-A-2,226.217. Thus, the conversation 
server 252, such as illustrated in Fig. 6, performs 
several different functions in the system 200 of the 
present invention. The conversation server 252 
handles communications with the conversation 
comunnlcation network 218. such as DEALING, 
maintains a database with respect to DEALING 
conversations, trade logs and tickets, drives various 
printers 226, 230. analyzes conversations in 
progress, and generates a serial ticket output feed, 
via path 234. for provision of this feed to the back 
office computer. By way of example, in accom- 
plishing this task, the conversation server computer 
252. may, by way of example comprise at least 4 
megabytes of memory, a 40 megabyte hard disk, a 
high density floppy, an Ethernet card with 512 
kilobytes of memory, conventional RS232 Serial 
Connections, an STB VGA extra memory video 
card generating a TTL output, and the appropriate 
software to communicate with the conversation 
communication network 218. These components 
are illustrated, by way of example, in Fig. 6. With 
respect to the associated printers 226, 230, the 
conversation printer 230 preferably prints conversa- 
tions as they are completed, whereas the ticket 
printer 226 preferably prints a single ticket for each 
matching trade as well as each confirmed video 
conversational negotiated trade. Of course, other 
printers may be associated with the integrated ter- 
minal controller 214, such as an audit trail printer 
280 or other standby printers if desired. With re- 
spect to the typical terminal computer 250, such a 
terminal computer 250 is illustrated in further detail, 
by way of example, in Fig. 5. Thus, by way of 
example, the terminal computer 250 such as an 
Intel 302 PC, which may also be employed for the 
conversation server 252 as illustrated in Fig. 6, 
preferably includes an RS232 input for a serial 
keyboard 240 and a serial mouse 242, a 51 2K 
Ethernet card, a conventional device for driving an 
analog screen 238, a 40 megabyte hard disk, and 
at least 3 megabytes of memory. It should be 
noted, that the terminal computer 250 illustrated in 
Fig. 5 is merely illustrated by way of example, and 
other conventional computers capable of use with 
the system 200 may also be employed instead of 
or in conjunction with terminal computer 250. 

It should be noted with reference to Fig, 2 that, 
although only one conversation server 252 is illus- 
trated as being connected to the local area network 
256, if desired, a plurality of conversation servers 
252 can be connected to the same section of the 
Ethernet Network 256, with there still being a single 



concentrator computer 254 for supporting matching 
connected to the local area network 256. By way of 
example, each conversation server 252 may sup- 
port up to 12 keystations for conversational trading 
5 and matching trades, with the concentrator com- 
puter 254, by way of example, being a Micro VAX 
2000. computer having a Ethernet interface, a hard 
disk, a pair of Asynchronous Serial lines to the 
matching communication network 220. and appro- 
10 priate software, such as referred to in the afore- 
mentioned EP and GB specifications. It should be 
noted that, by way of example, in the instance of 
12 keystations being associated with a given in- 
tegrated terminal controller 214. the 12 keystations 
75 need not all be supported by the same conversa- 
tion server 252, as mentioned above, even though 
the 12 keystations could be supported by a single 
concentrator computer 254. 

As will be described with reference to Figs. 10 
20 - 14, different screen layouts for the integrated 
screen display 238 may be provided, with Fig. 10 
illustrating the small font option preferably for use 
with large video screens such as 12 - 14 inch 
screens, and with Hgs. 13 and 14 illustrating the 
25 large font option preferably for use with smaller 
video screens such as 10 inch screens or when the 
user requires a simple display. Figs. 11 and 12 
illustrate the screen layout of the integrated screen 
display 238 in which, by way of example, a 14 row 
30 general display area is provided by overlaying the 
matching trade and conversational trade windows 
in the display, with Fig. 11 illustrating the integrated 
screen display 238 when matching has been se- 
lected by the user at the keystation, and with Fig. 
35 12 illustrating the integrated screen display 238 
when conversational trading has been selected by 
the user at the keystation, with the integrated 
screen display 238 toggling between the layout 
illustrated in Fig. 11 and the layout illustrated in 
40 Fig. 12 depending on the option selected. Prefer- 
ably, any of the screen layouts illustrated in Figs. 
10-14 may be selected by the user at the keysta- 
tion for providing the desired integrated screen 
display 238. In this regard, it should be noted that 
45 the keystation may be run under commercially 
available windowing software, such as Microsoft 
Windows 386 version 2.1, DOS 3.3 and the Win- 
dows version of the Workstation Environment 
(WSE). In the screen layout for the integrated 
50 screen display 238 illustrated in Fig, 10. the current 
entries in the market for potential automatic match- 
ing trades are preferably contained in area 260 with 
the results of the particular keystation' s recent 
automatic matching trade activity preferably being 
55 contained in the area immediately below and given 
reference number 262. As illustrated in Fig. 10, in 
the area immediately below that is the window 
which contains conversational trading activity and 
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may. by way of example, contain up to four such 
separate trading conversations of the type referred 
to in the aforementioned patents and EP and GB 
specifications relating to conversational trading. 
This area has been given reference numeral 264. 
Immediately to the right of that area in the screen 
layout illustrated in Fig. 10 is an area designated 
for displaying incoming calls as well as conversa- 
tion analysis summaries, such as referred to in the 
aforementioned patents and EP and GB specifica- 
tions; with conversation analysis summary being 
described and referred to in the aforementioned 
GB-A-2,226.217, and with this area being given 
reference numeral 266. In connection with the dis- 
play of multiple trading conversations in area 264, 
when conversational trading is selected by the in- 
tegrated keystation given the screen layout of Fig. 
10, preferably there is provision for a heading and 
at least 7 lines of the current conversation, and at 
least a heading and 1 line of text for up to three 
more trading conversations. Immediately below 
area 264 is a display area for Dealing or conversa- 
tional trading command responses, with that area 
being designated with reference numeral 268. Be- 
low that area is an area designated as the general 
display area, given reference numeral 270, which 
may preferably contain other market related in- 
formation, such as the REUTER MONITOR page. 
The same areas are preferably provided in the 
screen layouts illustrated in Figs. 11 and 12 with, 
however, the size of the general display area 270 
being increased so as to provide more room for the 
general display area 270 in the screen layout in the 
integrated screen display 238. As can be seen in 
Figs. 11 and 12, which relate to the same screen 
layout in which the general display area 270 is 
larger, such as 14 rows as compared with the 9 
rows provided in the example of Fig. 10, the larger 
size for the general display area 270 is accom- 
plished preferably by overlaying the matching trade 
area 260 and the conversational trade area 264, 
with Fig. 11 illustrating the screen layout when a 
matching trade option has been selected by the 
integrated keystation and with Fig. 12 illustrating 
the same screen layout when a conversational 
trade option has been selected by the integrated 
keystation. In this regard, it should be noted that in 
the option illustrated in Fig. 11, the conversational 
trade area 264 is, by way of example, 15 rows in 
height, and the matching trade area 260 is 7 rows 
in height, whereas in the option illustrated in Fig. 
12. the conversational trade area 264 has been 
increased to 22 rows, by way of example, by 
overlaying the 7 rows previously used for the 
matching area 260. Thus, as previously mentioned, 
the integrated keystation toggles between the 
screen layout of Fig. 11 and the screen layout of 
Fig. 12 depending on the trade option selected by 



the integrated keystation. With respect to the 
screen layouts illustrated in Figs. 13 and 14 for the 
integrated screen display 238, these screen layouts 
preferably have the same windows as the afore- 
5 mentioned screen layouts with, however, the num- 
ber of rows in various areas being reduced so as to 
accommodate larger characters in the display. In 
this regard, in Rg. 13, which illustrates the in-, 
tegrated screen display 238 layout when matching 
10 has been selected, the incoming calls area 266 is 
reduced in size as is the conversational trade area 
264, and the general display area 270 is the same 
size as in the option of Fig. 10. In Fig. 14, when the 
conversational trade option has been selected, the 
75 matching trade area 260 is overlayed by the con- 
versational trade area 264 which is increased in 
size, by way of example, from the 6 rows of Fig. 13 
to 13 rows in Fig. 14, and the incoming calls area, 
which is also used for conversation analysis sum- 
20 mary, 266 is increased in size. Preferably, the 
integrated screen display 238 has a high resolution, 
such as 640 pixels horizontally by 480 pixels verti- 
cally, which is in line with the normal VGA stan- 
dard, with the video being conventionally supplied 
25 by a Windows 386 driver and the STB VGA card in 
the terminal computer 250. 

Referring now to Fig. 15, an integrated key- 
board 240 contains keys which will enable the user 
to participate in both matching trades as well as in 
30 conventional trades in the system 200. For exam- 
ple, such a keyboard 240 may be obtained from 
Reuters, the assignee herein, under the designation 
DK101 or AK122/3, with all of the integrated key- 
boards 240 on a particular integrated terminal con- 
35 troller 214 preferably being of the same type. The 
system 200 uses keep alive signals from the in- 
tegrated keyboard 240 in order promptly to detect 
keyboard failure since such failure would effectively 
mechanically disable the trader or keystation from 
40 participating in both matching and/or conversational 
trades through use of the system 200. The keep 
alive signal is preferably a special character which 
is sent to the terminal computer 250 of the keysta- 
tion, at a predetermined periodic interval, such as 
45 every 4 or 5 seconds. This procedure is diagra- 
matically illustrated in Fig. 27. When the terminal 
computer 250 receives these special keep alive 
character, it preferably increments a keep alive 
counter, with this procedure being illustrated in Fig. 
50 28. The terminal computer 250 also preferably 
checks at a periodic interval, such as every 5 
seconds, whether the keep alive counter has been 
incremented. If the counter has not been incre- 
mented from the previous count, this indicates to 
55 the terminal computer 250 that the keep alive sig- 
nal or special character has not been received and 
that, consequently, the integrated keyboard 240 
may have failed. This procedure is illustrated in 
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Fig. 29. When the terminal computer 250 detects 
that the keyboard 240 has failed, the keystation 
removes all entries which it has placed in the 
matching market in connection with potential auto- 
matic matching trades and automatically terminates 
all Its current conversations associated with con- 
versational trading, and logs off. If desired, an 
alarm can also be provided at the keystation on the 
screen 238 indicating that the keyboard has failed. 
Thus, the keep alive signal periodically provided 
from the integrated keyboard 240 provides a heart- 
beat from the keyboard 240 to the terminal com- 
puter 250, which has been conventionally pro- 
grammed in accordance with thie procedures illus- 
trated in Figs. 28 - 29, and which automatically 
removes the offers and bids associated with that 
keystation from the matching host computer 224 
when it is detected that the integrated keyboard 
240 has failed by failing to provide an appropriate 
heartbeat or keep alive signal to the terminal com- 
puter 250. Summarizing the above, when a keep 
alive signal is not provided and the terminal com- 
puter 250 detects that it has not been provided 
because the keep alive counter has not been incre- 
mented, four actions occur; namely, the user is 
Informed that the keyboard 240 has failed, the user 
is logged off the keystation, contact is ended in all 
conversations which were active at the time in the 
conversational trading portion of the integrated 
trading system 200, and all prices which had been 
input to the matching host computer 224 by that 
keystation in connection with the automatic match- 
ing trading portion of the integrated system 200 are 
automatically removed from the matching host 
corpputer 224 database. Preferably, as shown and 
preferred in Fig. 29. if a keep alive signal is not 
detected in the first instance, then the terminal 
computer 250 retries again. If it is not detected 
after the second try, or second beat, then the 
terminal computer 250 indicates that the keyboard 
240 has failed. In this regard, if a mouse 242 is 
provided at the keystation, preferably, the keysta- 
tion may continue to operate if the mouse 242 fails - 
as long as the integrated keyboard 240 is still 
functioning. 

The function of logging on to the matching 
communication network 220 in order to effect auto- 
matic matching trades and to the conversation 
communication network 218 in order to effect video 
conversational negotiated trades is integrated, in the 
system 200. Fig. 18 is a state diagram illustrating 
the sequence of operations in connection with the 
integrated log on/log off to the system 200, with 
Figs. 19-20 illustrating a logic flow diagram of the 
logic operations performed by the system 200 in 
connection with the sequence of operations illus- 
trated in Fig. 18. Preferably, in order for the user or 
keystation to log on to the system 200. a user 



identifier is required as well as, preferably, a user 
password. Preferably, the user identifier is part of 
the set up data in the integrated terminal controller 
214 and must be entered correctly on tog on for 
5 the user. When this information is entered, the 
server database 262 and the integrated terminal 
controller 214 is accessed in order to obtain the 
subscriber name and to check the user I.D, If the 
user I.D. is known in the system 200. then the 
70 terminal or keystation 202 for example, is checked 
to see if it has been permissloned for matching. If it 
has, then the integrated keystation, 202 by way of 
example, tries to log on to the matching commu- 
nication network 220 with the input password, sub- 
75 scriber name and user I.D. If log on succeeds to 
the matching communication network 220 the 
keystation 202 has now been logged on to both the 
conversation communication network 218 and the 
matching communication network 220, since log on 
20 to the conversation communication network 218 
has not been inhibited. If, however, the keystation 
202 cannot log on to the matching communication 
network 220, then the keystation 202 is preferably 
disconnected from both the matching communtca- 
25 tion network 220 and the conversation communica- 
tion network 218 and the log on procedure is 
repeated, starting with the insertion of the user LD. 
and password. If. however, matching communica- 
tion for the keystation 202 is not enabled, as op- 
30 posed to attempting to log on and failing to log on, 
then conversation communication may still be en- 
abled with the conversation communication network 
218. 

Referring to the log off procedure, assuming 
35 matching communication has not been enabled but 
conversation communication with the conversation 
communication network 218 had been enabled at 
the time of the log off request, then the system 200 
checks to see if a conversation is in progress. If a 

40 conversation is in progress then the keystation 202 
may not log off. However if a conversation is not in 
progress, then the keystation 202 may be discon- 
nected from the conversation communication net- 
work 218. Similarly, if matching communication had 

45 been enabled and the keystation 202 had logged 
on to both the matching communication network 
220 and the conversation communication network 
218, the keystation 202 still could not log off if a 
conversation was in progress with that keystation 

50 202, The keystation 202 would have to first termi- 
nate the conversation. Furthermore, as shown and 
preferred in Fig. 20, if a log off request were 
received from that keystation 202 which had been 
logged on to both the communication network 220 

55 and the conversation communication network 218, 
then the system 200, and particularly the asso- 
ciated integrated terminal controller 214, would first 
determine whether any trading conversation or 
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matching was in progress associated with that 
keystation 202 and, assuming it was not then in 
progress, the terminal controller 214 would then 
determine whether there were any outstanding 
matching tickets expected as a result of trades 
which had been completed but had not yet had a 
ticket generated. If there were no outstanding 
matching tickets expected, then the keystation 202 
could disconnect from both matching and con- 
versational trading. If however, there were outstand- 
ing matching tickets expected, then preferably the 
user would be given the option to confirm a log off, 
or cancel a log off, or wait for the tickets. If the 
user confirmed a log off or had received the tickets 
after waiting for them, the user could then dis- 
connect from matching and conversational trading. 
If the user merely cancel led the log off, then 
conversation and matching trading would stifl be 
enabled. This would also be true if a conversational 
or matching trade associated with that keystation 
were still in progress. As also shown and preferred 
in Fig. 19. if the keyboard 240 either failed in any 
state in the sequence of operations or was discon- 
nected during any state in the sequence of oper- 
ations, the keystation 202 would be disconnected 
from both matching and conversational trading until 
reconnection of the keyboard 202. It should be 
noted from the above, that a keystation 202 may 
solely log on to conversational trading or automatic 
matching trading if that is its capability or desired 
intent. The purpose of the integrated log on is to 
enable a single keystation 202 to log on to both 
different types of trading systems, assuming it has 
that capability, with a single log on procedure. The 
software associated with the tog on/log off proce- 
dure illustrated in Figs. 18 - 20 is contained, by 
way of example, in Table A annexed hereto as an 
Appendix, and is written in C language for use with 
the 80386 terminal computer 250 in which this 
software is resident- 
Referring now to Figs. 21 - 24, typical screen 
displays for the integrated screen display 238 are 
shown which contain trading information in connec- 
tion with both matching trades and video conversa- 
tional negotiated trades by the keystation 202 after 
it has logged on to both the matching communica- 
tion network 220 and the conversation communica- 
tion network 218. Fig. 21 illustrates the presence of 
both conversational trading data and matching trad- 
ing data on the integrated screen display 238, Fig. 
22 illustrates the same integrated screen display 
238 when the YOURS key on the keyboard 240 of 
Fig. 15 has been depressed and the YOURS dia- 
logue box is about to be transmitted. Fig. 23 illus- 
trates the same integrated screen display 238 
when a matching trade has been automatically 
executed and a match notification has been pro- 
vided from the matching host computer 224 to the 



integrated terminal controller 214 associated with 
the keystation 202. The logic flow diagram illustrat- 
ing the operation of the integrated terminal control- 
ler 214 in response to such a match notification is 

5 shown in Fig. 25 to be described in greater detail 
hereinafter. Fig. 24 illustrates the same integrated; 
screen display 238 with, this time, a conversational 
negotiated trade having been completed as shown 
on the screen and in the conversation analysis area 

10 266. 

The logic flow diagram of Fig. 25 may be 
accomplished by conventional programming of the 
integrated terminal controller 214. When the match 
acknowledgment, to be. described in greater detail 

75 with reference to Fig. 9 and EP-A-90305753 is 
received from the matching host computer 224. the 
match is displayed on the integrated screen dis- 
play 238 which was a party to the matching trans- 
action. In addition, an audit trail message is sent to 

20 the database server 262 which forms part of the 
conversation server 252 of the integrated terminal 
contorller 214 and the audit trail is stored at the 
database server 262. A reply with the match . num- 
ber is sent to the keystation and when the match 

25 number is received by the keystation 202 a match 
acknowledgement, termed MATCH ACK. is sent to 
the matching host computer 224. As further shown 
and preferred in Fig. 25, the database server 262 
may also be preferably connected to the audit trail 

30 printer 280 for printing of audit messages. The 
procedure for printing such audit trail messages is 
also illustrated in the logic flow diagram of Fig. 25. 

Fig. 26 is a logic flow diagram of the operation 
of the integrated terminal controller 214 in re- 

35 sponse to receipt of a matching ticket or conversa- 
tion ticket at the completion of an automatic match- 
ing trade or video conversation negotiated trade, 
respectively, and may, of course also be imple^ 
mented by conventional programming of the in- 

40 tegrated terminal controller 214, When a match 
ticket is received at the integrated keystation 202 
from the matching host computer 224, the match 
ticket is sent to the database server 262 contained 
in the conversation server 252 of the integrated 

45 terminal controller 214 in the form of what is 
termed a pseudo conversation, with a typical 
matching ticket corresponding to such pseudo con- 
versation being illustrated in Fig. 16. This match 
ticket is then stored at the database server 262 and 

50 can be accessed to support review of displays on 
the integrated screen display 238 via the terminal 
computer 250 or to support retrieval of tickets over 
the ticket output feed 234 to the back office com- 
puter. Similarly, when a conversation ticket is con- 

55 firmed at the completion of a video conversational 
negotiated trade, the conversation ticket, which 
may be in the form shown by way of example in 
Fig. 17, is sent to the database server 262 con- 

10 
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tained in the conversation server 252 of the in- 
tegrated terminal controller 214 along with the con- 
versation, the ticket is then stored at the database 
server 262 with the conversation and, like the 
matching ticket, may be accessed to support re- 
view of displays on the integrated screen display 
238 via the terminal computer 250 and to support 
retrieval of tickets over the ticket output feed 234. 
Fig. 26 also illustrates the operation of the printing 
of a ticket, either a match ticket or a conversation 
ticket, by the ticket printer 226 utilizing the ticket 
data stored at the datalDase server 262. 

Apart from the differences described above 
with respect to the employment of the integrated 
terminal controller 214 and integrated keystation 
202 so as to enable the integration of automatic 
matching trades and video conversational negoti- 
ated trades in the system 200, the function and 
operation of the various components of the system 
200 relating to the conversation commnication net- 
work 218 and matching communication network 
220 are preferably the same as described in the 
respective aforementioned patents and EP and GB 
specifications which relate to these functions. How- 
ever, for purposes of clarity, certain portions of 
these patent applications shall be repeated herein 
with respect to Figs. 3 and 4 relating to video 
conversational negotiated trades; Figs. 7-9 and 30 
relating to automatic matching trades; and Figs. 31- 
34 relating to the ticket generation scheme for 
providing the ticket output feed via path 234 or 
236. 

Referring now to Figs. 3 and 4, as previously 
mentioned,. the integrated trading system 200, pro- 
vides conversation analysis with respect to the 
video conversational negotiated trades effected by 
the system 200, with this conversation analysis 
being summarized in area 266 of the integrated 
screen display 238. This analysis is preferably ac- 
complished in the same manner as described in 
the aforementioned GB-A-2,226,217, in which con- 
text sensitive! prompts are employed, with the con- 
versation analysis software driving the analysis 
driven prompts and letting the user know in real 
time where the user is in the conversation that is 
going on between counterparties, such as foreign 
exchange traders, so that the appropriate prompt 
selection menu may be employed based on the 
analysis of the key points in the conversation as it 
proceeds in real time. This real time conversation 
analysis, as described in GB-A-2,226,217, also en- 
ables the preparation of Dealing or conversation 
tickets in real time while the deal is being arranged 
through, the use of artificial intelligence techniques 
to analyze the conversation dialog and generate 
the ticket. Thus, as described in GB-A-2.226.217, 
this is accomplished in an expert type of system. 
The context sensitive or analysis driven prompts 



are preferably employed to speed up the dealer 
input in connection with video conversational nego- 
tiated trades in system 200 of the present invention 
since time is generally of the essence, such as in 

5 foreign exchange dealings. Of course, the system 
200 need not be limited to foreign exchange deal- 
ing and may be used in connection with any type 
of video communication where rapid input of con- 
versation information is desired. Of course, as is 

10 also described in GB-A-2,226.21 7, the system may 
be employed for data capture of offline deals as 
well. Because of this conversation analysis, the 
system 200, is capable of generating error mes- 
sages to the user to alert the user if an inconsis- 

75 tency is detected in the conversation being ana- 
lyzed in connection with a video conversational 
negotiated trade, such as if the value date is in- 
proper or the range of prices is inproper, by way of 
example. As described in GB-A-2,226,217, apart 

20 from the conversation analysis driven prompts and 
associated features, the system is substantially 
similar to other conversational video systems de- 
veloped by the assignee herein and described in 
the aforementioned GB-A-2,227,625. In this regard, 

25 the conversation communication network 21 8 is 
preferably basically the same type of communica- 
tion network as illustrated in Fig. 13J, by way of 
example, of US-A-4.525,779 and the same refer- 
ence numerals have been used in Fig. 4 as are 

30 used in US-A-4,525,779 for like functioning compo- 
nents such as for the concentrators 48 and 110, 
and for the nodes 44 and 42, but with the host 
computer given reference number 38 in Fig. 13J, of 
US-A-4,525,779. and with the storage device hav- 

35 ing been given reference numeral 205 in the exam- 
ple of Fig, 4. The London Taker in . Fig. 4 is 
assumed to be the integrated terminal controller 
216 at client site 212 and the New York Maker is 
assumed to be the integrated terminal controller 

40 214 at client site 210. Of course, other packet 
switching communication networks could be em- 
ployed for the conversation communication net- 
works 218 in place of the network illustrated in Fig. 
4. The terminal controller shown in Fig. 13J of US- 

45 A-4.525,779 is replaced by the integrated terminal 
controller 214 or 216 in the system of Fig. 1, with 
this integrated terminal controller preferably includ- 
ing a conversation analyzing terminal controller 
portion 214a, such as illustrated in Fig. 3, which 

50 enables real time conversation analysis of the vid- 
eo conversations between, for example, the New 
York Maker at client site 210 and the London taker 
at client site 212, and the provision of context 
sensitive analysis driven prompts. In this regard. 

55 and as described in the aforementioned GA- 
2.227.625, conversation tickets may be printed 
based on real time conversation analysis. In addi- 
tion, as was also previously mentioned, the in- 
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tegrated keystations 202, 204, 206, 208 preferably 
also have a conventional mouse 242, such as the 
mouse described in the aforementioned Gb-A- 
2,227,625, such as for providing the fast contact 
features described therein and illustrated in Rgs. 
35-36 which correspond to Figs. 11-12 of GB-A- 
2.227,625. If these features are not desired, the 
mouse 242 may be omitted. Moreover, it should be 
noted, that both parties to a conversation need not 
have an integrated terminal controller 214. 216 
containing a conversation analyzing terminal con- 
troller portion 214a. in that the analysis server 264 
may be omitted, however, the party will then not 
have the benefit of real time conversation analysis 
to provide context sensitive or analysis driven 
prompts or automatic ticket generation or inconsis- 
tency notification based on such real time con- 
versation analysis- 

With respect to the conversation anaylzing ter- 
minal controller portion 214a illustrated in Fig. 3, 
the line server 260, database server 262 and con- 
versation analysis server 264 are ail preferably 
80386 computers, such as a COMPAQ 80386 
based computer. In addition, as was previously 
mentioned, the terminal computers 250 are also 
preferably 80386 based computers, each of which 
provides outputs to its associated integrated screen 
display 238, integrated keyboard 240, and mouse 
242. The previously mentioned local area network 
256 further permits comhnunication between appro- 
priate ones of the various computers 260, 262, 252 
and 250 in accomplishing the conversation analy- 
sis, context sensitive prompts, inconsistency alert, 
and automatic ticket generation functions of the 
system 200. The line server 260 preferably serves 
as an interface between the terminal computers 
250 and the appropriate concentrator 48 or 110 in 
the conversation communication network 218. The 
functions of the database server 262 have already 
been described with respect to the integrated ter- 
minal controller 214. As for the conversation analy- 
sis server 264, this server 264 preferably stores the 
conversation analysis software, such as the soft- 
ware described in detail in the aforementioned GB- 
A-2,227,625 and analyzes the conversation in real 
time and provides the desired context sensitive or 
analysis driven prompts to the Maker or Taker's 
screen 238, depending on whom the conversation 
analyzing terminal controller portion 214a is asso- 
ciated with at the time, provides conversation tick- 
ets to the database server 262 associated with it, 
and alerts the user to inconsistencies in the con- 
versation by providing such alerts to the integrated 
screen display 238. Of course, although in the 
example of Fig. 3, separate servers 260. 262 and 
264 are shown as comprising the conversation 
server 252 of the integrated terminal controller 214. 
these servers can be combined into a single com- 



puter, if desired, with each keystation 202, 204. 
206. 208 still being supported by a dedicated ter- 
minal computer 250 and with, as previously men- 
tioned, these keystation terminal computers 250 

5 being linked to the servers 260, 262, 264 by the 
conventional local area network 256. Preferably, 
communication over this local area network 256 
uses a virtual connection such as provided by the 
MS-NET standard variant- In addition, preferably ail 

to of the data about each conversation in progress, 
such as up to 24 such conversations for a given 
terminal controller 214. by way of example, is held 
in a global array with each element in this array 
pointing to a structure of type CONVDATA in ac- 
ts cordance with the software illustrated, by way of 
example, in the aforementioned GB-A-2,227.625. 
This is a type which holds the various network 
handles associated with the conversation, the text 
buffer for the conversation, and so on. It also 

20 preferably includes an element identified as 
SAVEDDATA of type ANALYSISDATA, which is 
used to store the state of the conversation analysis. 
The conversation analysis is driven by the receipt 
of packets of text from the various keystations 202, 

25 204, 206. 208 comprising the subscriber population 
of the conversation communication network 218. 
These successive chunks of text arrive in AN- 
ALYSE TEXT PACKETS which are directed to the 
correct procedure by the environment, which has 

30 been informed of the destination of the input mes- 
sages by a call to NetRegisterReply in the proce- 
dure Ov-main in section caserver.c in the software 
described in the aforementioned GB-A-2.227,625. 
The incoming packets of text are directed to the 

35 procedure fn ReplyAnalysisMessages in the sec- 
tion camesage.c. When an ANALYSE TEXT packet 
is received for a conversation, (Current Conv) is set 
to point to the CONVDATA structure for the appro- 
priate conversation, and the saved analysis state 

40 and ticket are preferably copied into the working 
areas pointed to by the globals (Ticket) and 
(Analysis Data). Then the procedure Re- 
plyAnalyzeText in the section camesage.c of the 
software described in the aforementioned GB-A- 

45 2,227.625 is called to check the request. If appro- 
priate, the analysis is initializeid. This happens 
when text is deleted, for example, by an interrupt. 
Any new text is added to the conversation and the 
C library procedure setjump of the aforementioned 

50 software is called to store the current C context for 
the longjump return from parsing. This, call to set- 
jump returns zero, and then the parsing routine 
parse of the aforementioned software is preferably 
called to analyze the conversation from the last 

55 saved state. When the parsing is terminated by 
reaching the end of the text currently held, the 
longjump call returns to the point at which setjump 
was called with a non zero reply, and the analysis 
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is wrapped up by notifying the keystation 202, by 
way of example, of any change to the analysis. 
Preferably, the conversation analysis, such as ex- 
emplified by the software described in the afore- 
mentioned GB-A-2,227.625, always starts on the 
parse procedure. 

It should be noted, as described in the afore- 
mentioned GB-A-2.227.625, that preferably conver- 
sation analysis is performed on words or groups of 
symbols which are extracted by nextsym in section 
read.c of the conversation analysis software listing 
described in the aforementioned GB-A-2,227.625. 
Thus, until the conclusion of a stage of analysis, 
the symbols found are preferably stored in a buffer 
so that the analysis can backtrack if the current 
hypothesis proves incorrect: if a reanalysis is in 
progress, and there is such a queue of extracted 
symbols, nextsym preferably selects the next item 
in the queue. Otherwise, nextsym preferably reads 
a symbol from the text using the routine readsym 
described in the aforementioned software, which 
procedure preferably obtains characters from the 
text buffer using the routine readch. At this stage, 
fully replaciaable synonyms, such as PLEASE and 
PLS, are merged to a single symbol code, held 
under the identifier (symbol). Other words are pref- 
erably allocated to 'a symbol such as S currency 
and individually identified by a number held in 
(symval). In the case of a currency identifier, this 
preferably identifies the actual currency, assuming 
that the conversation is being employed for foreign 
exchange. In addition, as was previously men- 
tioned, the preferred conversation, analysis 
software-described in the aforementioned GB-A- 
2,227,625 includes an error detection procedure 
which checks the deals as they occur in real time, 
reporting erroneous or suspect conditions to the 
user based on analysis of the conversation, with 
the error messages preferably being placed below 
the insert line in the integrated screen display 238 
and the suspect flag data being highlighted in the 
summary analysis display area 266 on the inte- 
grated screen display 238 so as to provide an alert. 
It should be noted that in employing the conversa- 
tion analysis function in the system 200 the general 
display area .270 in the integrated screen display 
238 may be used to display additional financial 
information, such as a REUTER MONITOR page, 
prompt menus, analysis of the conversations, etc, 
with the analysis of the conversations normally 
preferably replacing the REUTER MONITOR dis- 
play. This area 270, may also be used for prompts 
and expanded analyses. With respect to the start- 
ing of conversations in the integrated system 200, 
such conversations can basically be started in 
three ways; namely, the user can contact another 
dealer,, the user can accept the call from another 
dealer, or the user can enter the complete deal. 



using the CAPTURE function, as an offline deal. 
The particular menus displayed, preferably depend 
initially on how the conversation is started, with the 
person making the contact normally being referred 
5 to as the Market Taker and the person accepting 
the contact normally being referred to as the Mar- 
ket Maker. 

With respect to the printing of conversation 
tickets, assuming conversation analysis is em- 

70 ployed in the system 200, the conversation tickets 
are preferably created in the system 200 as the 
system extracts information by analyzing conversa- 
tions, with the display of the ticket being generated 
appearing on the integrated screen display 238. 

J5 Preferably, only one analysis can be associated 
with one conversation and, after a user confirms 
the analysis with respect to a current conversation, 
a ticket can be printed on the ticket printer 226 
depending on whether it is the Market Maker or the 

20 Market Taker, respectively, when the conversation 
js next terminated or printed. Preferably, the ticket 
printer 226 has the same characteristics as the 
conversation printer 230; namely, it accepts serial 
data and it prints on continuous paper. As a con- 

25 versation takes place, the associated conversation 
analysis area on the integrated screen display 238 
preferably shows a summary of the analysis in- 
formation which, if desired, can become a fully 
expanded version of a current analysis which is 

30 then displayed in the general display area 270. 
When the conversation is terminated and saved, 
preferably the analysis is saved with it. Preferably, 
conversations and analyses are saved and deleted 
only as more storage is required. Before conversa- 

35 tion analysis can be confirmed, however, preferably 
it must contain at least the following information 
about the deal: the deal type, the deal direction, 
the currency or currencies, the amount, the rate or 
rates, and the value date. Thereafter, the user can 

40 confirm the conversation analysis by pressing the 
CONFIRM key on the keyboard 240. Once an 
analysis has been set into the confirming mode, 
the next time the conversation is ended on the 
dealer's screen 238, a ticket is preferably printed 

45 and, thereafter, the conversation cannot be edited 
any further. If the analysis has not been confirmed, 
it can be marked as cancelled or wrong at any time 
during a real or offline conversation or when wrap- 
ping up a conversation by pressing the CANCEL or 

50 WRONG keys on the keyboard 240. Thus, in order 
to generate a ticket on the ticket printer 226 asso- 
ciated with a video conversational negotiated trade, 
the conversation being analyzed is set to the CON- 
FIRMING state which ends the analysis. 

55 Although a more detailed description is includ- 

ed in EP and GB specifications, particularly EP-A- 
90305753. the automatic matching trade compo- 
nent will be briefly described with reference to 
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Figs. 7-9 and 30. In this regard. Fig. 7 corresponds 
to Fig. 1 of EP-A-90305753, with the nnatching 
communication network 220 corresponding to refer- 
ence numeral 22 in Fig. 1 of this publication, and 
with the central matching host computer 224 cor- 
responding to reference numeral 20 in Fig. 1 of this 
publication. In addition, the client sites in Fig. 7 
have been given reference numerals 210 and 212 
as opposed to the reference numerals 26a and 26b 
employed in Fig. 1 of this publication, since these 
client sites 210, 212 contain the presently preferred 
integrated terminal controllers 214, 216, and with 
the keystations 24a and 24b of Fig. 1 of this 
publication being replaced by the presently pre- 
ferred integrated keystations 202, 204, 206, 208. 
Similarly. Fig. 8 corresponds to Fig. 2 of this pub- 
lication with the same exceptions, and Fig. 9 cor- 
responds to Fig. 3 of this publication with the same 
exceptions. Similarly, Fig. 30 corresponds to Fig. 6 
of this publication with the same exceptions with 
respect to the integrated keystations 202 and 206 
being substituted for keystations 24a and 24b, and 
with the reference numeral 224 being used for the 
central matching host computer 20 employed in 
Fig. 6 of this publication. As shown and preferred 
Fig. 8, the matching component for effecting auto- 
matic matching trades in the integrated trading 
system 200 is shown in which trading is effected 
through anonymous matching as opposed to 
through the previously described video conversa- 
tional negotiated trades. Thus, in connection with 
the distributed matching communication network 
220 of the system 200. the matching host com- 
puter 224 serves as a computerised exchange in 
which its central role 15 to identify a buyer and 
seller who are willing to trade with one another 
based on specified criteria, such as price, quantity 
and credit. When such a matching event occurs, 
assuming the integrated keystation 202 has logged 
on to the matching communication network 220 in 
the manner previously described with reference to 
Figs. 18-20, preferably the buyer and seller are 
informed of the trade and sufficient information is 
then provided to them through the respective in- 
tegrated terminal controllers 214 and 216 in order 
to complete the physical clearing of the transaction. 
As described in the aforementioned EP and GB 
specifications, in order to support this central func- 
tion, various support functions are required, one of 
which is preferably the maintenance of summary 
market information on the participant's keystation 
integrated display 238 at the various client sites 
210, 212. Preferably, at all times, those keystations 
202, 204, 206 and 208 which form part of the 
matching communication network 220 will display 
the best inside price for every instrument traded 
through that network 220. Although all four keysta- 
tions 202. 204, 206. 208 are represented as being 



part of the matching communication network 220, 
as welt as being part of the conversation commu- 
nication network 218. this need not be the case. 
The best inside price is preferably defined to be 

5 the highest value bid and the lowest value offer in 
the network 220. Preferably, the prices are dis- 
played together on the integrated screen display 
238 with the quantity bid or offered at the specified 
price so that the trader at the respective integrated 

10 . keystation 202, 204. 206. or 208 can observe the 
market activity. By observing, the market activity, 
the trader can decide whether to enter a bid, or 
enter an offer into the market in an effort to com- 
plete a matching transaction, as opposed to the 

;5 manner of openly negotiating a trade by exchang- 
ing discretionary messages through the conversa- 
tion communication network 218 to complete a 
video conversational negotiated trade. Thus, with 
resfDect to the client site 210 or 212 to the central 

20 matching host computer 224 will preferably result 
in one. or more messages, represented by refer- 
ence numeral 32, going directly back as a directed, 
message to the client site, 210 in this example, 
which initiated the transaction message. Another 

25 effect of the transaction message 30 being sent to 
the central matching host computer 224 is that for 
certain sorts of transactions, a broadcast message 
34 is generated by the central matching host com- 
puter 224 which is then delivered to all client sites 

30 210, 212 attached to the central matching host 
computer 224 via the matching communication net- 
work 222. Thus, the directed response or the di- 
rected message 32 only goes back to the particular 
client site 210 and, more particularly, the particular 

35 integrated keystation. 202 by way of example, at 
that client site 210 which initiated the transaction 
message, whereas the broadcast message. 34 
goes to all client sites 210, 212 and all the various 
integrated keystations 202, 204, 206, 208 asso- 

40 ciated at those client sites 210, 212 which are part 
of the matching communication network 220. As 
was previously mentioned, by way of example, in 
Fig. 7, a typical client site 210 is shown as having 
keystations 202 and 204, although the number of 

45 keystations available at a client site is merely limit- 
ed by the capacity of the system and the desired 
processing time. With respect to the distribution of 
the functionality in connection with the matching 
communication network 220 of the integrated trad- 

50 ing system 200, the matching communication net- 
work 222 preferably does not really play a part in 
that it'is transparent to transactional information. By 
this what is meant is that when the transactional 
information leaves the client site 210, for example, 

55 it could be, if desired, encrypted or garbled in a 
way that the only other entity which could under- 
stand it would be the central matching host com- 
puter 224 and that would be irrelevant to the func- 
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tion of the matching communication network 222 
since the network does not look at the messages, 
does not process the messages, and merely trans- 
fers these messages to the appropriate parts of the 
matching communication network 220, matching 
communication network 220, the system 200 es- 
sentially maintains a book of bids and offers in the 
matching host. computer 224 and a user or keysta- 
tion 202, 206, by way of example, and a client site, 
such as client sites 210 and 212. respectively, 
interacts with the book by submitting bid. offer, hit. 
or take transactions, such as illustrated in Fig. 8. 
The order entry function is preferably convention- 
ally achieved through data entry using the inte- 
grated keyboard 240, the mouse 242. or any other 
conventional data entry tool. The matching host 
computer 224 validates the transaction request, 
processes the bid, or the hit or take, according to 
the rules of the market, and attempts to find match- 
es between this new entry and the other bids or 
offers posted in the matching communication net- 
work 220 book. If a match is found, then the trade 
is automatically executed, the participants to the 
trade are informed, all databases and trader 
screens 238 are updated as to the quantities traded 
and the quantities remaining and, if desired, a 
clearing agency may be informed as to the details 
of the trade so that payment and exchanges may 
be completed. If on. the other hand, a match can 
not be found, then the matching communication 
network 220 preferably either disposes of the entry 
for hit or take or keeps the entry for bid or offer for 
later processing. Preferably, in all cases, transac- 
tions are processed to completion according to 
certain rules and the various client sites 210. 212 
preferably receive real time updates of the new 
status of the trading instruments, assuming that 
they are members of the matching communication 
network 220. Thus, as shown and preferred in Fig. 
8, the client site systems 210, 212. only two of 
which are shown by way of example in Fig. 8, 
when the associated keystations 202, 204, 206, 208 
have selected the matching trade option, submit 
transactions, such as represented by reference nu- 
meral 30 in Fig. 7, to the central matching host 224 
via the matching communication network 222, 

As will be explained in greater detail hereinafter 
with reference to Fig. 30, the submission of a 
transaction 30 from a 



such as to the matching host computer 224. In this 
regard, the network 220 is functioning similar to a 
paired cable in that it is there to pass the informa- 
tion back and forth. Of course, the network 220 has 
various other-communication functions which, how- 
ever, for purposes of understanding the matching 



component of the integrated system 200, are un- 
necessary to go into. Suffice it to say that prefer- 
ably the matching communication network 220 
uses a protocol which can be termed hierarchal 
5 fan-out in which one node transmits to multiple 
nodes which in turn transmit to multiple other 
nodes. Thus, matching communication network 220 
helps implement broadcast capabilities Integrated 
with a message switching network to achieve full 
10 tolerance in broadcast distribution. It should be 
noted, when a match occurs, the central, matching 
host computer 224 will preferably send directed 
messages or responses to all of those parties in 
the system 200 that were involved in the match, so 
75 that, in some instances 2,3 or more client sites 
210, 212 may be involved in receiving the directed 
message. However, this still differs from the broad- 
cast message which is sent to all client sites ir- 
respective of their involvement in a particular 
20 match. 

Referring now to Fig, 8, this figure illustrates a 
typical data flow in the integrated system 200. for 
the entry of a bid or entry of an offer, with the 
matching communication network 220, as was pre- 
25 viously mentioned, being transparent to transac- 
tional information Integrated keystation 202, by way 
of example, submits a bid transaction to the central 
matching host computer 224 through the matching 
communication network 220, via the terminal com- 
30 puter 250 and the concentrator computer 254. The 
directed message or directed response 32 which it 
receives back from the central matching host com- 
puter 224 is termed a bid acknowledgment or BID- 
ACK. This acknowledgment is a command ac- 
35 knowledgment which is preferably followed by an 
entry position message and is. as previously men- 
tioned, directed directly back to the keystation 202 
via the concentrator computer 254, the local area, 
network 256, and the terminal computer 250. In 
40 addition, as shown and preferred in Fig. 8, a bid 
update message is broadcast by the central match- 
ing host computer 224 to all keystations 202, 204, 
206, 208 in the system 200 which have logged on 
to the matching communication network 220. such 
45 as represented by reference numeral 34a in Fig. 8. 
This broadcast message 34a preferably occurs if 
this new bid 32a was a new best bid in the system 
200 with respect to the matching component, or 
was an additional quantity being bid at the best 
50 price in the system 200 with respect to the match- 
ing component. Thus, if this new bid 32a is at the 
highest price or better or higher, then it will result 
in a bid update broadcast message 34a going out 
throughout the system 200 to all keystations which 
55 have logged on to the matching communication 
network 220. In addition, as also shown by way of 
example in Fig, 8, if it is desired to disseminate an 
external ticker 60, then the ticker information 60 will 
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also be provided of the best bid or best offer- 
Preferably, the same procedure is followed with 
respect to entry of an offer with the messages, in 
this instance, being identified as offer, given refer- 
ence numeral 51, offer acknowledgment or OFFER- 
ACK, given reference number 32b, and the broad- 
cast message for offer update* being given refer- 
ence numeral 34b. 

Referring now to Fig. 9. the data flow in the 
integrated system 200, is illustrated with respect to 
a situation in which there was a hit bid resulting in 
a trade. In this situation, there is substantially more 
activity than the situation previously described with 
reference to Fig. 8, Thus, as shown and preferred 
in Fig. 9. if the integrated keystation 206 submits a 
transaction called "hit bid", represented by refer- 
ence numeral 62, to the central matching host 
computer 224 via the matching communication net- 
work 220, a hit acknowledgment or HIT/ACK. repre- 
sented by reference numeral 64, is provided back 
to keystation 206 as a directed message. At that 
point, the central matching host computer 224 will 
recognize that a match is possible because the "hit 
bid" message says that keystation 206 is willing to 
trade at the bid price. Assuming that credit is OK 
and does not play a role beyond that in this trans- 
action, the central matching host computer 224 
determines that a match is possible but, preferably, 
before committing to the match, it may get in- 
volved in a risk linriiting protocol using a transaction 
desk 70. as described in the aforementioned EP 
and GB specifications which determines whether 
the trade is possible, and if so, acknowledges this 
to the central matching host computer 224. Assum- 
ing that a trade is possible, then a match occurs. At 
that point several messages are generated from the 
central matching host computer 224 through the 
matching communication network 220. One of 
these messages is termed the match message, 
given reference numeral 65, which is a directed 
message that goes to the bidder, which in this 
instance is keystation 206, and to the keystation 
202, which originally owned the bid. Thus, in this 
instance directed messages go to more than one 
integrated keystation 202. 206 logged on to the 
matching communication network 220. Preferably, 
every match must be acknowledged so there is a 
match acknowledgment message, MATCH-AGK 
which comes back from the buyer and seller 
keystations 202 and 206 and. is used to determine 
that the match was in fact received correctly and 
that the deal can be considered complete at that 
point. The response of the integrated terminal con- 
troller 214. 216 to such a match notification has 
been previously discussed with reference to Fig. 25 
which represents software resident in the various 
terminal computers 250 associated with the keysta- 
tions and in the integrated terminal controllers 214. 



216. themselves, in the respective data servers 
262, as a result of conventional programming. In . 
addition, a broadcast message is generated that a 
trade has occurred which trade update message, 

5 given reference numeral 67, may possibly cause a 
new best bid to occur or could affect the quantity 
or price at the top of the book. Again, if the trades 
and best bids go into the ticker 60, then this 
information is provided to the ticker as well; Simi- 

70 larly, if clearing information is provided to a clear- 
ing house, this too occurs as represented by refer- 
ence numeral 69. In addition, as shown and pre- 
ferred , trade tickets may also be generated, such 
as previously referred to with reference to Fig. 26. 

75 Thus, trade ticket information is also preferably 
provided to the participating integrated keystations " 
202, 206 in the above example, so that the trade 
tickets can be generated with respect to the match- 
ing trades. 

20 It should be noted that the concentrator com- 

puter 254, which interfaces with the matching com- 
munication network 220, preferably always commu- 
nicates with the associated conversation server 252 
containing the database server 262 which controls 

25 the ticket generation, via the keystation terminal 
computer 250. Thus, the concentrator computer 
254 and the conversation server 252 are tied to- 
gether in the integrated terminal controller 214, 216 
through the local area network 256 and the asso- 

30 ciated keystation terminal computers 250. Conse- 
quently, the software associated with the "ticket 
received" function illustrated in Fig. 26, which may 
be accomplished by conventional programming, is 
resident in the terminal computers 250 associated 

35 with the individual keystations and in the data serv- 
er 262 portion of the conversation server 252 in the 
integrated terminal controller 214, 216. 

With respect to the details of the various books 
enriployed in the distributed matching component of 

40 the integrated trading system 200. these details are 
described in the aforementioned EP and GB speci- 
fications. Suffice it to say that the central matching 
host computer 224 maintains a host book database 
comprising all of the active bids and offers in the 

45 integrated trading system 200 which have been 
provided by keystations which have logged on to 
the matching communication network 220 and that 
each of the respective integrated keystations 
logged on to the matching communication network 

50 220 has an associated local data base keystation 
book which comprises a subset of the host book, 
with the content of each of the keystation books 
having an associated display depth range control- 
lable by the central matching host computer 224 

55 and being updatable by transaction update broad- 
cast messages received from the matching host 
computer 224 through the matching communication 
network 220. In this regard, reference is made to 
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Fig. 30 which illustrates the two collections of in- 
formation which are being maintained at the client 
sites 210, 212 which have logged on to the match- 
ing communication network 220. As shown by way 
of example in Fig. 30, one of these collections of 
information is the book for each instrument which is 
maintained at the keystation sites. 202 and 206, in 
the above example, and have been given reference 
numerals 112 and 110 respectively in Fig. 30. 
Another book maintained at each site is a local 
entry data base or order book which has been 
given reference numerals 1 1 6 and 1 1 4, respec- 
tively, in Fig. 30. As previously mentioned, there is 
also the host or system book data base associated 
with the central matching host computer 224 which 
has been given reference numeral 118 in Fig. 30. 
Each time a client site 210 or 212, by way of 
example, starts up as an integrated keystation log- 
ging on to the matching communication network 
220, such as by using the log on software and 
procedure illustrated by way of example in Figs. 18 
- 20 and in Table A annexed hereto as an Appen- 
dix, which is written in C language for use with an 
80386 computer, and which is resident in the termi- 
nal computer 250 of the integrated keystation, the 
integrated keystation which is logging on to the 
system 200 is preferably initially empty and re- 
quests download of the currently active books from 
the matching host computer 224. Preferably, sepa- 
rate books are maintained for each trading instru- 
ment, and each of these books is maintained at a 
given display depth. In this regard, it should be 
noted that an update broadcast message is prefer- 
ably only broadcast when the price information is 
inside the assigned display depth that has been 
assigned by the matching host computer 224. With 
respect to the local entry database or order books 
114, 116. these order books 114, 116 are prefer- 
ably updated by directed messages from the 
matching host computer 224 and/or record the 
orders of the particular integrated keystation 202. 
206, by way of example, which had been sent to 
the matching host computer 224 through the 
matching communication network 220. In this re- 
gard, these order books 114, 116 are preferably 
kept current so that there is a listing only of orders 
which are still present in the central matching host 
computer 224 from the respective integrated 
keystations 202 or 204, by way of example. 

This order database 114 and 116 gets modi- 
fied, such as through the removal of data, due to 
various occurrences, such as when a complete 
match has occurred for a given order and an entry 
remove message is provided, or if it is a partial 
match you may get an entry message that tells you 
that only a partial match has been done against 
that order. The match notification, which was pre- 
viously referred to, preferably refers to a particular 



order that is contained in the order database 114 or 
116 and indicates what quantity or portion of the 
order has been matched. If ail of the order has 
been matched, the entire order is then preferably 

5 deleted from the respective order database 114 or 
116. By way of example, if a bid were put in for ten 
million yen at a price of 127 and the display was 
enabled, that is the display depth was set to some- 
thing greater than or equal to one, then the central 

70 matching host computer 224 would preferably con- 
struct a broadcast message, which is the afore- 
mentioned update broadcast message, which 
would inform all client sites 210,212 that a new bid 
had been added to the Yen book, assuming that 

15 were the instrument being traded. The update mes- 
sage would instruct an operation block which would 
say add to index one the ten million at 127. As for 
the other parameters in the update message, add 
index would equal one, type would equal bid, quote 

20 would equal 127, and quantity would equal ten 
million at 127. As for the other parameters in the 
update message, add index would equal one, type 
would equal bid, quote would equal 127 and quan- 
tity would equal ten million. In the above example. 

25 the transaction achieves two functions. The first 
function it achieves is that a bid is submitted and 
the matching host computer 224 responds to the 
integrated keystation 202 submitting the bid that 
the bid was accepted and that there was no am- 

30 biguity in that the bid is definitely in the system 
200; the system 200, namely the matching host 
computer 224, has it; and the local entry database 
116 has it. The other function indicates that the bid 
was of a certain characteristic that the rest of the 

35 "matching trading world" in the system 200 should 
know about, and this is accomplished as a result of 
the broadcast message which was generated to all 
of the client sites 210, 212 logged onto the match- 
ing network 220, whicti were then told about this in 

40 summary as opposed to being given, all of the 
detailed information. It should be noted that, as- 
previously mentioned, in terms of functional opera- 
tion, the entry of a bid to the system is the same 
as entry of an offer. 

45 In the situation when a trade occurs, this 

means that . a matching offer is present in the 
system, the matching host computer 224 has ac- 
cepted that matching offer, and sends back the 
acknowledgment command, in effect retrieving the 

50 existing book on Yen, in the above example, finds 
out that there is ten million yen at 127 in the book, 
adds to that the newly entered fifteen million at 
127, and is aware that it has positioned fifteen 
million at 127. The matching host computer 224 

55 then does the match up including that ten million 
and does the trade, taking out the existing bid, so it 
reduces that amount to zero million at 127 leaving 
over five million at 127 on the offer side. In this 
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instance, as will be further explained with reference 
to Fig. 30. at least two directed messages have 
been sent, actually four having been transmitted to 
the client sites 210,212 that are involved in the 
trade. The seller will get an indication that his Yen 
bid has traded by means of a match notification 
and he will, thereafter, be informed who the coun- 
terparty was after the match has been made. The 
clearing and settlement of the trade will then pref- 
erably be the responsibility of the subscribers. The 
counterparty who originally transmitted the offer 
and entry position message saying that it had a 
Yen offer positioned greater than the bid will then 
get an entry positioned yen offer at five million at 
127 and will get a match notification saying that, 
with respect to his offer, ten million of his original 
fifteen million has traded with the party who will 
then be identified. Lastly, the update broadcast 
message will be constructed and broadcast to all 
client sites 210, 212 logged on to the matching 
network 220 to update the trading book. That up- 
date message will preferably, in the above exam- 
ple, contain two operation blocks, one which will 
remove the bid information from the client book 
and the second which will post the new five million 
offer which remains on the offer side and will show 
that a trade took place. In addition, as was pre- 
viously mentioned, if desired, ticker information will 
also be provided in the update message saying 
what traded, keeping track of the cummulative vol- 
ume, the net change, the number of changes, the 
high limits, the low limits and so forth. It should be 
noted that preferably only the integrated keystation 
that, either executed the transaction, for example 
keystation 202, or was involved somehow in that 
transaction wiir receive the directed message with 
respect thereto and not other integrated keysta- 
tions, such as keystation 204, at the same client 
site 210. whereas with respect to broadcast mes- 
sages all integrated keystations logged on to the 
matching network 220 at alt client sites receive 
these messages. If desired, with respect to credit, 
this can be controlled on a client site by client site 
basis as opposed to a keystation basis. Thus, in 
the system 200, the matching communication net- 
work 220 has two functions, one of which is di- 
rected message delivery and the other of which is 
broadcast message delivery. 

Referring now to Fig. 30 in greater detail, the 
matching communication network 220 which, as 
was previously mentioned, is transparent to trans- 
actional information, has been omitted for purposes 
of explanation of the message flow in the system in 
accordance with the method of the present inven- 
tion. For purposes of the example of Fig. 30, in- 
tegrated keystation 202 can represent any keysta- 
tion which originates a transaction and integrated 
keystation 206 can represent any keystations which 



are involved as counterparties in the transaction 
which, as was previously mentioned can be more 
than one keystation at more than one location. The 
keystations 202 and 206 are normally remotely 

5 located from each other such as, for example, 
keystation 202 being at a client site 210 in New 
York and keystation 206 being at a client site 212 
in London, which are the same locations used in 
the example of Fig. 4 relating to the transaction of 

10 video conversational negotiated trades, although 
the locations need not be the same. 

In addition, the keystations 202 and 206 are 
remotely located from the central matching host 
computer 224. In order to understand the message 

75 flow illustrated in Fig. 30. we will assume that the 
originating keystation 202 is receiving a display of 
the keystation book database located at keystation 
202 on its integrated screen display 23i8. Assuming 
that the operator at the integrated keystation 202 

20 then desires to enter a bid or an offer, either of 
which will be termed an order, this information is 
input to the keystation 202 via conventional means, 
such as the integrated keyboard 240 or a mouse 
242. by way of example. The keystation 202 then 

25 preferably validates the order and maintains its 
local order data base or local entry data base 116. 
The order, instead of being a bid or an offer, could 
be a hit or a take for a particular trading instrument 
as well since all of these various items would 

30 constitute an entry of an order. After the order has 
been entered, validated, and, the order data base 
116 maintained, a transaction message is built and 
sent as a directed message to the central matching 
host computer 224 through the matching commu- 

35 nication network 220. This is represented by refer- 
ence numeral 120 in Fig. 30. This transaction mes- 
sage 120 is received by the central matching host 
computer 224 and contains transaction information. 
At this point, preferably the central matching host 

40 computer 224 sends back a directed message, 
termed a command acknowledgment message and 
given reference numeral 122, to inform integrated 
keystation 202 that the transaction message 120 
has been received- The transaction message 120 is 

45 time-stamped by the central matching host com- 
puter 224 at this point. Preferably the display 238 
of keystation 202 will indicate "please wait" until 
the transaction message 120 has been acknowl- 
edged. Preferably, such acknowledgment happens 

50 relatively quickly, such as in about two seconds, by 
way of example. The central matching host com- 
puter 224 then preferably processes the transaction 
message 120 against the central matching host 
computer 224 stored copy of the system or host 

55 book which is contained in the host book data base 
118. At this point, the central matching host com- 
puter 224 preferably either adds the entry of the 
transaction or the order from integrated keystation 
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202 to the host book data base 118 or matches 
that entry against existing bids and offers contained 
in the host book data base 118. Once that process- 
ing is completed, the central matching host com- 
puter 224 is ready to generate output messages 
not only to the originating keystation 202. but pos- 
sibly to other keystations, such as the counterparty 
keystations represented by 206 and, assuming that 
an update message is required, to all keystations 
which have logged on to the matching communica- 
tion network 220. Thus, matching host computer 
224 generates directed messages back to each of 
the keystations involved in the matching transac- 
tion, such as the originating keystation 202. and! 
assuming that there is a match, keystation 206 as 
the counterparty keystation, and generates the up- 
date broadcast message to all keystations logged 
on to the matching network 220. It should be noted 
that, as previously mentioned, a single transaction 
message 120 from keystation 202, whether it is a 
hit, or a take, or a bid. by way of example, could 
result in multiple matches. For example, if keysta- 
tion 202 wants to hit the bid for a quantity of 20. it 
is possible that to satisfy that order more than one 
match could be involved such, as for example, four 
or five different matches, particularly, since the 
keystation book at keystation 202 merely displays 
accumulated summaries of the bids or offers. 

If multiple matches occur, then, thereafter, the 
identity of all of the counterparties involved in the 
multiple matches are displayed on the integrated 
screen display 238 of the originating keystation 202 
for settlement purposes. Thus, on any given trans- 
action, there will always be directed messages 
involving the transaction originator and involving 
one or more counterparties or affected parties in 
that trade or transaction. If the market is an auction 
market, then it preferably has a price depth of one 
so that this determines how many prices the cen- 
tral matching host computer 224 can maintain with 
only one price being maintained in an auction 
market. When a new bid goes in which betters the 
existing bid in an auction market, the existing bid is 
actually removed and effectively cancelled in the 
book. Preferably, after all of the directed messages 
are generated to the counterparties, and the asso- 
ciated directed message acknowledgments, such 
as represented by reference numerals 124, 126, 
128 and 130 in Fig. 30, the update broadcast 
message, represented by reference numeral 132 in 
Fig. 30, is sent to all keystations logged on to the 
matching network 220 regardless of whether or not 
they were involved in their particular matching 
transaction. It should be noted that preferably the 
first six steps illustrated in Fig. 30 with respect to 
the central matching computer 221 are all essenr 
tialty asynchronous to any outside events. When 
the keystations 202 and 206 receive the update 



broadcast message, it will be processed . against 
the local keystation book database 110. 112 and 
the local copy of the book will be maintained. As 
was previously mentioned, it should be noted that 

5 this local keystation book 110. 112 is not an exact 
carbon copy of the central system book 118. but 
rather is only a selected subset of it which com- 
prises an accumulated summary of bids and offers 
within the assigned display depth. Thus, preferably, 

10 Fig. 30 illustrates a generic template for the pro- 
cessing of messages throughout the integrated 
trading system 200 in accordance with the method 
of the present invention in order to provide the 
distributed functionality of the system to keysta- 

;5 tions logged on to the matching network 220. 

It should be noted that the concept of originat- 
ing keystation and counterparty keystation moves 
around with each transaction so that for each trans- 
action the originator may be different and may» for 

20 different transactions occurring at the same time, 
be an originating keystation in one instance and a 
counterparty keystation in another instance, in ad- 
dition, there are other instances in which the 
keystation may merely be a bystander and not 

25 involved in the particular transaction at all. Prefer- 
ably the control of the overall distributed matching 
system is maintained by the central matching host 
computer 224 which operates in accordance with a 
set of rules which govern how the transactions are 

30 processed. Preferably, the central matching host 
computer 224 processes transactions against a 
particular trading instrument in time order of entry 
into the system. In this regard it should be noted 
that it is not time entry of orders per se but time 

35 entry of orders related to a particular trading book 
or trading instrument. Thus, there would be time 
order entry assigned to Yen. a different time order 
entry consideration assigned to Deutsch Marks, 
and so forth if the trading instruments were foreign 

40 exchange currencies. 

In Figs 31-34, which correspond to Figs. 4-8 
and 8 of GB-A-2,224,141 . the trading ticket output 
is shown. Pressign the TICKET key on the in- 
tegrated keyboard 240 causes the expanded analy- 

45 sis display mode to be entered or stored in the 
data base server 262. As was previously men- 
tioned, in this mode, the expanded analysis for the 
current conversation, assuming the keystation is 
connected to the conversation communication net- 
so work 218, is displayed on the screen 238. The 
expanded analysis preferably shows the full con- 
tents of all the fields that can appear in the analysis 
except that payment instructions may, if necessary, 
be truncated. In the case of forward deals, prefer- 

55 ably the information for both value dates is shown, 
requiring four transactions. While in expanded ana- 
lysis display mode, the expanded analysis on dis- 
play is preferably kept up-to-date with the con- 
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versation. Swapping between two conversations 
would automatically preferably swap between the 
two expanded analyses so that the one for the 
current conversation was always visible. The ex- 
panded analysis display mode preferably remains 
in effect until a different use of this display area on 
the screen 238 is requested. Preferably, if a print- 
out of the conversation analysis is requested, the 
output on the conversation printer 230 is similar to 
that of the displayed window, although the payment 
instructions may be moved to a separate line if 
desired. With respect to printing a conversational 
ticket with the ticket printer 226, the format of the 
ticket is preferably similar to the expanded analysis 
such as the conversational trading ticket illustrated 
in Fig. 17, however the order of the information 
may be changed to present the more critical in- 
formation first. Of course, although the creation and 
storage of a ticket has been described in terms of 
real time conversation analysis, such a system is 
not necessary for the generation of tickets per se 
which merely requires a local data base storage of 
trading tickets no matter how these trading tickets 
are dynamically created, with the data base server 
262 providing such a local data base storage, by 
way of example, in the integrated terminal control- 
ler 214, 216 for both conversational trading tickets 
and match tickets, with the match tickets being 
stored as pseudo conversation, such as illustrated 
in Fig. 16, by way of example. 

For purposes of better understanding the pre- 
ferred ticket output feed 234, 236, the preferred 
ticket output protocol and process will now be 
described for handling the transfer of trading ticket 
information between the local data base server 262 
and the back office computer. In this regard, with 
reference to U.S. Patent No. 4,745,559 incorpo- 
rated by reference herein, the local data base serv- 
er 262 is analogous to the local data base de- 
scribed in U.S. Patent No. 4,745,559. except, as 
will be described in greater detail hereinafter, with 
respect to the various differences as it relates to 
the presently preferred ticket output protocol and 
process employed in the system 200. Although, the 
preferred ticket output protocol preferably em- 
ployed in the system 200 preferably employs field 
identifiers or FIDs which are analogous to the field 
identifiers referred to in the aforementioned U.S. 
Patent No. 4.745,559, the information contained 
therein is totally different. In place of the record 
identifier codes or RICs referred to in the afore- 
mentioned U.S. Patent No. 4.745,559. the ticket 
output protocol process preferably employs unique 
deal identifiers which correspond to the ticket num- 
ber on the printed deal ticket as well as to the 
integrated terminal controller 214.216 which con- 
tains the local data base server 262 containing that 
record. Thus, the deal or trading ticket identifier 



includes the terminal controller identifier as well as 
a ticket number, with deals preferably being given 
sequential numbers in order of their confirmation. 
The sequence is preferably in the range of 1 - 

5 999999, by way of example, for each terminal 
controller 214,216. The deal identifier preferably 
starts with the terminal controller identifier and a # 
and is followed by the sequential number, such as, 
for example, AAAA#1 23456 for deal number 

70 .123456 on terminal controller AAAA, In addition to 
retrieving the deal per se, the status of the data in 
the terminal controller system can also preferably 
be retrieved using the terminal controller identifier 
AAAA#INFO, by way of example. 

T5 Preferably, as will be described in greater de- 

tail hereinafter, the data base server 262 can sup- 
ply two kinds of data to be retrieved about the 
deals being conducted by the keystations asso- 
ciated with that terminal controller 214. 216; name- 

20 ly information on a deal, and status information on 
what is stored In the data base. As will be de- 
scribed in greater detail hereinafter, it is the up- 
dates from the status record which are preferably 
looked at to see if there is a change in status 

25 indicating that a new trade has arrived, which per- 
mits rapid transfer of trading information, such as 
the trading tickets, without the need for continuous 
polling of the various terminal controllers 214,216. 
It should be noted that each terminal controller 

30 214,216 keeps its own unique record o£ deals and 
has its own unique set of deal identifiers which are 
independent of the other terminal controllers 214, 
216 associated with the back office computer, as- 
suming more than one terminal controller is asso- 

35 ciated therewith, since a portion of the record iden- 
tifier is the unique identification of the terminal 
controller 214, 216 itself. A data record associated 
with a terminal controller identifier or TCID, is pref- 
erably a collection of data items with each data 

40 item being assigned a unique Field Identifier Num- 
ber or FID. The presently preferred ticket output 
protocol employed in the system 200 in accor- 
dance with the method of the present invention 
preferably uses the FID number to identify each 

45 data item within a message. Preferably, records in 
the system are grouped into classes, such as for a 
deposit deal, or a swap deal or a single deal, such 
as a spot or outright deal, with each class prefer- 
ably relating to a set of FIDs called a Field List. 

50 The Field List is analogous to a template except 
that it relates to the format of the transmission of . 
the data as opposed to the display per se. with the 
Field List defining which collection~of "data items 
will be received for that class of record. This Field 

55 List is preferably contained in the record response 
of the data base server 262 to the request of the 
back office computer for trading ticket information. 
Since single deals such as spot or outright 
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deals; swap deals; and deposit deals have certain 
characteristics unique from each other, unique field 
identifiers must preferably be provided to distin- 
guish these types of deals in the preferred ticket 
output protocol. 

Preferably, requests for the status of the deal 
or trading ticket data base contained in the local 
data base server 262 of a particular terminal con- 
troller 214, 216 will provide information to the back 
office computer on the earliest and latest deal 
identifiers stored at the local data base server 262, 
with the date and time of the trading tickets. This 
information would permit the back office computer 
to determine the range of trading tickets available 
for retrieval. 

Preferably, all fields within the messages trans- 
mitted between the local data base server 262 and 
the back office computer contain ASCII characters 
which makes them suitable for display on a video 
terminal with little or no additional formatting, thus 
making this data feed ideal for quick implementa- 
tion in a data display system, such as via the 
integrated screen display 238. 

Rg. 31 diagrammatically illustrates the various 
portions of the trading ticket output system con- 
cerned with the presently preferred trading ticket 
output protocol of the system 200. Thus, a conven- 
tional serial line handler provided by the operating 
system is employed with, for convenience of ex- 
planation, the input and output being separately 
illustrated as the input handler 800 and the output 
handler 802. The input process 804 preferably ex- 
tracts input bytes from the serial line via the input 
handler 800 and places the: in an input buffer 806. 
The input buffer 806 performs the checks for input 
packets and checksums and can also set flags to 
ask the ticket output process 808 to generate the 
control characters ACKNOWLEDGE and NO AC- 
KNOWLEDGE at appropriate points in the output 
stream. The input process 804 also preferably de- 
tects these control characters, such as ACKNOWL- 
EDGE and NO ACKNOWLEDGE, at the appropriate 
points in the input stream, with the occurrence of 
these control characters being tested for by the 
ticket output process 808 when it has sent a mes- 
sage. The ticket output process 808 is preferably 
scheduled regularly and has several independent 
tasks, the main ones of which are preferably taking 
confirmed bytes from , the input buffer 806 and 
placing them in a message buffer 810, scanning 
the message 810 to find the next complete mes- 
sage if available and, when found, checking the 
message. If the message is faulty, an appropriate 
error response is sent to the output message buffer 
812- If, however, the message is valid, appropriate 
flags are set to request the required action. Prefer- 
ably, no further messages are then handled by the 
ticket output process 808 until the action is com- 



plete. If a ticket or status report is requested by an 
input message, then the ticket output process 808 
preferably gathers the data from the ticket data 
base 814 and places it in the defined format, 

5 determined by the Field List, in the output mes- 
sage buffer 812. When a message has been as- 
sembled in the output message buffer 812, the 
ticket output process 808. preferably adds the ap- 
propriate control bytes and transfers it to the output 

10 handler 802. passing as many characters, as the 
output handler 802 can accept at a time. until the 
whole message has been transferred to the back 
office computer from the local data base server 
262. The ticket data-base process 814 is preferably 

75 modified to support updates of the status data in 
the ticket output protocol. The addition is prefer- 
ably required when the data base is modified by 
the addition of a new trading ticket or the removal 
of an old ticket. In these cases, the ticket data base 

20 process 816 preferably sets a flag so that the 
update will be created by the ticket output process 
808, with the flag being cleared, as appropriate, by 
the ticket output process 808. The ticket data-base 
process 816 is preferably designed so that it adds 

25 a ticket to the end of the data base 814 and 
obtains space as necessary by removing the earii-: 
est tickets from the beginning of the data base 814. 
Either of those changes alters the status of the data 
base 814 so that when there is a status check by 

30 the back office computer, the back office computer 
is, thus, advised of the addition of a trading ticket 
by detecting the change in status. This is indicated 
to the ticket output process 808 by setting out a. 
flag which is cleared, when appropriate, by the 

35 ticket output process 808. 

Fig. 32 further illustrates the presently pre- 
ferred operation of the ticket output process 808 
which, as can be seen, is entered at frequent 
intervals. The logic preferably gives priority to re- 

40 sponses to requests, and handles one request at a 
time. A request preferably remains in the input 
message and analysis stage 810 until it has been 
answered. When any message has been created 
for output, preferably the ticket output process 808 

45 is dedicated to the output of the message until it 
has been ACKNOWLEDGED or has been transmit- 
ted a given number of times without acknowledg- 
ment. Preferably, when no message is being out- 
put, the ticket output process 808 checks to see if 

50 an input message has requested a trading ticket. Is 
so, the trading ticket is retrieved, a message is 
created according to the type of ticket by use of 
the Field List, and the new message is marked for 
output to the back office computer. When no ticket 

55 is being requested, the ticket output process 808 
preferably checks if the status record has been 
requested. If so. the status data is preferably ob- 
tained and the status record is set up for output in 
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a similar way to the trading ticket output. If, how- 
ever, no status is requested, then the ticket output 
process 808 preferably checks to see if the status 
has been nnarked as changed by the ticket data 
base process 816. If a change is detected, the flag 
indicating the change is preferably cleared, The 
logic then preferably checks if the status record is 
currently requested in an updating mode. If this 
has occurred, the new status is preferably output 
on the line and the ticket output process 808 cre- 
ates a new status in the output message buffer 812 
and then arranges that it will output the message. 
In the aforementioned implementation, the status 
record is preferably updated by retransmission of 
the whole status record. If none of the above con- 
ditions exist, the ticket output process 808 then 
preferably tries to find a complete new input mes- 
sage. If this succeeds, the ticket output process 
808 preferably analyzes the input message. A valid 
message causes a change in the analysis data. 
The analysis of a valid message requesting data 
sets flags which then cause the ticket output pro- 
cess 808 to generate the requested output as it is 
rescheduled repeatedly. Other valid messages just 
change the current state of the analysis data, 
whereas invalid messages cause the ticket output 
process 808 to generate an appropriate error re- 
sponse. The above described procedure is illus- 
trated in the flow diagram of Fig, 32. 

Referring now to Fig. 33 the operation of the 
terminal controller data base server 262 when a 
new trading ticket has been generated is shown. 
Thus, when a new deal is generated, as repre- 
sented by reference numeral 850, the trading ticket 
corresponding to the deal is added to the list of 
deals, with altocatiions of the deals or tickets being 
in numerical order as was previously described, 
such as represented by reference numeral 852. 
The status record is then updated, giving the last 
deal number, as represented by reference numeral 
854, and a determination is made as to whether the 
deal status is being retrieved with an update, as 
represented by reference numeral 856. If the deal 
status is being retrieved with an update, the update 
is sent to the back office computer to update the 
status record, such as represented by reference 
numeral 858. and if it is not, then the routine ends, 
as represented by reference numeral 860. 

Referring now to Fig. 34, a flow chart is shown 
of the operation of the local data base server 262, 
with respect to requests for tickets received by the 
local data base server 262 from the back office 
computer. Thus, the trading ticket requested by the 
back office computer is requested by Deal Iden- 
tifier, which, as previously mentioned, does not 
specify the type of deal. This is represented by 
reference numeral 900. The type of deal indicated 
is then looked at in the ticket record being re- 



trieved, as represented by reference numeral 902. 
and the ticket output message is then formatted 
using the Field List specific to the type of deal, as 
represented by reference numeral 904 in Fig. 34. 

5 The formatted record response message, which 
now contains information as to the type of deal, as 
well as the various parameters and values asso- 
ciated with them, is then sent to the back office 
computer in the appropriate deal format, based on 

70 the Field List contained in the retrieved record and, 
for the first time, the back office computer finds out 
what type of deal was involved with the request. 
This is represented by reference numeral 906. It 
should be noted, as previously mentioned, the re- 

75 quest by the back office computer and the re- 
sponse to the back office computer from the local 
database server 262, contain a "Tag" which iden- 
tifies the particular request being made. 

Thus, by employing the integrated trading 

20 method of the present invention, the speed and 
reliability of both automatic matching and negoti- 
ated video conversational trades may be combined 
in a single system to provide individual subscribers 
with maximum flexibility and optimal efficiency to 

25 effectuate and complete the type of trade demand- 
ed by the time and circumstances available, and to 
generate a ticket corresponding to the trade, ir- 
respective of the type of trade transacted. 

In the first aspect of the invention as defined 

30 by Claim 1, the system may further comprise a 
second interface means connectably disposed be- 
tween at least one of said keystation means in said 
second plurality of keystation means and said first 
communication means for selectively interfacing 

35 said one of said keystation means in said second 
plurality of keystation means with said first commu- 
nication means, said one of said keystation means 
in said second plurality of keystation means com- 
prising video display means capable of displaying 

40 both said bids and said offers. The common data 
input means may further comprise means for tog- 
gling between said matching trades and said video 
conversational negotiated trades for selectively ef- 
fectuating said trades via said one of said keysta- 

45 tion means in said second plurality of keystation . 
means. On of the keystation means in said second 
plurality of keystation means further comprises 
means for selectively varying the content of the 
display on said common video display means in 

50 response to said toggling of said data inpijt means. 

In the first aspect of the invention as set out in 
Claim 1, the keystation means may comprise a 
computer means. Whether it does or not. the inter- 
face means may comprise a conversation seiner 

55 means for interfacing said video conversational tex- 
tual data messages with said first communication 
means. Whether it does or not. the interface means 
may comprise a concentrator computer means for 
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interfacing said bids and said offers witti said first 
connmunicatlon means. When the keystation means 
does comprise a computer means, the data input 
means may further comprise means for periodically 
providing a keep alive signal to said keystation 
computer means, said keystation computer means 
comprising means responsive to said periodically 
provided keep alive signal for deleting said selec- 
tively provided bids and offers selectively provided 
from said keystation means associated with a given 
data input means when said keep alive signal pe- 
riodically provided from said associated data input 
means is not provided. The means responsive to 
said periodically provided keep alive signal may 
comprise means for automatically terminating con- 
tact with all other keystation means in said system 
for a given keystation means associated with said 
given data input means when said keep alive signal 
periodically provided from said associated given 
data input means is not provided. 

In the first aspect of the invention as set out in 
Claim 1, the interface means may comprise a 
uniquely identifiable local data base for initially 
collecting trading ticket information relating to both 
said automatically matched trades for said trading 
instruments and video conversational negotiated 
trades for said trading instruments, and means for 
communicating said collected trading ticket infor- 
mation to a remote back office data base: whereby 
a common ticket generation scheme hnay be em- 
ployed in said integrated trading system for said 
trading instruments irrespective of the type of 
trade. The interface means may further comprise 
and integrated terminal controller means connec- 
tably disposed between said keystation means, 
said first communication means, and said uniquely 
identifiable local data base for selectively interfac- 
ing said keystation means with said first commu- 
nication means. Alternatively, the interface means 
may further comprise means for initially collecting 
said trading ticket information corresponding to 
said trades as self-contained integral trading ticket 
records and storing said self-contained integral 
records at said uniquely identifiable local data 
base. The collecting and storing means may further 
comprise means for storing said self-contained in- 
tegral records at said uniquely identifiable local 
data base unique identification and a sequential 
number corresponding to the order of confirmation 
of each of said trades at said local data base. The 
sequential numbers may be independent of the 
type of trade conducted through said integrated 
system. The system may further comprise means 
for retrievably requesting trading tickets from said 
local data base for providing said trading tickets to 
said remote back office data base independent of 
the type of trade involved. 

In the first aspect of the invention as set out in 



Claim 1, the system my further comprise a host 
computer means for maintaining a host book data 
base comprising all of the active bids and offers 
associated with said matching transactions in the 

5 system by trading instrument, at least one of said 
first plurality of keystation means comprising a 
transaction originating keystation means for provid- 
ing a bid on a given trading instrument to said 
system for providing a potential matching transac- 

10 tion and at least one of said second plurality of 
keystation means comprising a counterparty 
keystation means for providing an offer on said 
given trading instrument involved in said potential 
matching transaction, said first communication 

75 means interconnecting said host computer means, 
said transaction originating keystation means and 
said counterparty keystation means in said inte- 
grated system for enabling data commnication 
therebetween for effectuating said automatically 

20 provided matching transactions. The host computer 
means may comprise means for processing said 
matching transaction for a given ti-ading instrument 
in time order entry to said system. Alternatively, 
both said transaction originating keystation means 

25 and said counterparty keystation means for said 
potential matching transaction may each have an 
associated local data base keystation book com- 
prising a subset of said host book. The keystation 
means associated with said potential matching 

30 transaction may comprise means for displaying 
said associated keystation book on video display 
means. Alternatively, the content of each of said 
keystation books may have an associated display 
depth range controllable by said host computer 

35 means and being updatable by transaction update 
broadcast messages received from said host com- 
puter means through said first communication 
means. The transaction originating, keystation 
means and said counterparty keystation means 

40 comprise means responsive to said received trans- 
action update broadcast messages for updating 
said associated keystation books and means for 
providing directed messages to said host computer 
means corresponding to said bid and offer, respec- 

45 tlvely. said direct messages updating said host 
book. The host computer means may comprise 
means for conditionally providing said transaction 
broadcast update meassages to said keystation 
means associated therewith in response to the 

50 presence of an update condition, said update con- 
dition comprising updating of said host book and 
said received bid or offers within said host book 
having a relative value compared with other bids or 
offers within said host book which is within said 

55 keystation book display depth range of relative 
values; whereby controllable subsets of a dis- 
tributable system trading book may be selectively 
provided to trading keystations in said integrated 
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system from the host for controHably masking the 
available trading market for said automatically 
matched trades. 

In the first aspect of the invention as set out in 
Claim 1, the data input means may further com- 
prise means for periodically providing a keep alive 
signal to said interface means, said interface 
means comprising means responsive to said pe- 
riodically provided keep alive signal for automati- 
cally terminating contact with all other keystation 
means in said system for a given keystation means 
associated with said given data input means when 
said keep alive signal periodically provided from 
said associated given data input means is not 
provided. 

In the second aspect of the invention as set out 
in Claim 8, the common data input means may 
further comprise means for toggling between said 
matching trades and said video conversational ne- 
gotiated trades for selectively effectuating said 
trades via said first keystation means. The first 
keystation means may further comprise means for 
selectively varying the content of the display on 
said common video display means in response to 
said toggling of said data input means. The means 
for selectively varying the display content of said 
common video display means may comprise 
means for varying the format of said display on 
said common video display means in response to 
said toggling of said data input means. 

In the second aspect of the invention as set out 
in Claim 8. the system may further comprise a 
second integrated terminal contorller means con- 
nectably disposed between at least a second 
keystation means and said data communication 
network for selectively interfacing said second 
keystation means with said data communication 
network, said second keystation means comprising 
a common video display means capable of display- 
ing both said bids and said offers associated with 
said matching transactions and said video con- 
versational textual data messages associated with 
said negotiated trades, and a common data input 
means for selectively inputting both said video con- 
versational textual data messages to said data 
commnication network through said second inte- 
grated terminal controller means for effectuating 
said video conversational negotiated trades and 
said bids and said offers to said data commnication 
network through said second integrated terminal 
controller means for effectuating said automatically 
provided matching transactions. 

In the second aspect of the invention as set out 
in Claim 8, the integrated terminal controller means 
may comprise a concentrator computer means for 
interfacing said bids and said offers with said data 
communication network. Alternatively, it may com- 
prise a conversation server means for interfacing 



said video conversational textual data messages 
with said data communication network. In this case, 
the conversation server means may further com- 
prise common data base means for integrating 

5 trade data relating to both said bids and said offers 
and said video conversational textual data mes- 
sages. Alternatively, the integrated terminal control- 
ler means may further comprise a concentrator 
computer means for interfacing said bids and said 

10 offers with said data communication network. The 
integrated terminal controller means may further 
comprise a local area network means for tieing said 
conversation server means and said concentrator 
computer means together. The first keystation 

75 means may comprise a terminal computer means, 
said terminal computer means being tied to said 
local area network means. 

In the second aspect of the invention as set out 
in Claim 8. the first keystation means may com- 

20 prise a computer means. The data input means 
may further comprise means for periodically pro- 
viding a keep alive signal to said first keystation 
computer means, said first keystation computer 
comprising means responsive to said periodically 

25 provided keep alive signal for deleting, said selec- 
tively provided bids and offers selectively provided 
from said first keystation means associated with 
said data input means when said keep alive signal 
periodically provided from said data input means is 

30 not provided. The means responsive to said pe- 
riodically provided keep alive signal comprises 
means for automatically terminating contact with all 
other keystation means in said system for said first 
keystation means associated with said given data 

35 input means when said keep alive signal periodi- 
cally provided from said associated data input 
means is not provided. 

In the second aspect of the invention as set out 
in Claim 8, the integrated terminal controller means 

40 may comprise a uniquely identifiable local data 
base for initially collecting trading ticket information 
relating to both said automatically matched trades 
for said trading instruments and video conversa- 
tional negotiated trades for said trading instru- 

45 ments, and means for communicating said col- 
lected trading ticket information to a remote back 
office data base; whereby a common ticket genera- 
tion scheme may be employed in said integrated 
trading system for said trading instruments ir- 

50 respective of the type of trade; The integrated 
terminal controller means may further comprise 
means for initially collecting said trading ticket in- 
formation corresponding to said trades as self- 
contained integral trading ticket records and storing 

55 said self-contained integral records at said uniquely 
identifiable local data base. Alternatively, the in- 
tegrated terminal controller means may comprise a 
conversation server means for interfacing said vid- 
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eo conversational textual data messages with said 
communication network. The conversation server 
means may comprise means for communicating 
said collected trading ticket information to said 
remote back office data base- 
In the second aspect of the invention as set out 
in Claim 8, at least said first keystation means may 
further comprise pointer means for locating data 
display areas in a windowed textual video display 
on said video display means, and storage means 
for retrievably storing a plurality of unique keysta- 
tion contact signals capable of initiating conversa- 
tion contact with at least one of said other keysta- 
tion means through said data communication net- 
work, each of said other keystation means having a 
unique associated identification code, said keysta- 
tion contact signals corresponding to said unique 
associated identification codes, said windowed tex- 
tual video display comprising a windowed display 
of at least one of said unique associated iden- 
ficiation codes, said pointer means comprising 
means capable of locating said windowed display 
of said unique associated identification code in said 
windowed textual video display and providing a 
conversational contact message signal to said 
keystation storage means in response thereto for 
retrieving said unique keystation contact signal cor- 
responding to said located unique associated iden- 
tification code for providing a calling signal to said 
corresponding keystation means through said data 
commnication network. The pointer means may 
comprise a mouse. 

In the second astpect of the invention as set out 
in Claim 8, the system may further comprise inter- 
face means comprising said integrated terminal 
controller means and a uniquely identifiable local 
data base for initially collecting trading ticket in- 
formation relating to both said automatically 
matched trades for said trading instruments and 
video conversational negotiated trades for said 
trading instruments, and means for communicating 
said collected trading ticket information to a remote 
back office data base, whereby a common ticket 
generation scheme may be employed in said in- 
tegrated trading system for said trading instru- 
ments irrespective to the type of trade. 

In the second aspect of the invention as set out 
in Claim 8, the system may further comprise a host 
computer means for maintaing a host book data 
base comprising all of the active bids and offers 
associated with said matching transactions in the 
system by trading instrument, at least said first 
keystation means comprising a transaction originat- 
ing keystation means for providing a bid on a given 
trading instrument to said system for providing a 
potential matching transaction and at least on of 
said other keystation means comprising a counter- 
party keystation means for providing an offer on 



said given trading instrument involved in said po- 
tential matching transaction, said data communica- 
tion network interconnecting said host computer 
means, said transaction originating keystation 

5 means and said counterparty keystation means in 
said integrated system for enabling data comm- 
nication therebetween for effectuating said auto- 
matically provided matching transaction. Both said 
transaction originating keystation means for said 

10 potential matching transaction each have an asso- 
ciated local data base keystation book comprising 
a subset of said host book. Alternatively or jn 
addition, both said transaction originating keysta- 
tion means and said counterparty keystation means 

75 for said potential matching transaction each have 
an associated local data base keystation book com- 
prising a subset of said host book. 

In the second aspect of the invention as set out 
in Claim 8, the data input means may further 

20 comprise means for periodically providing a keep 
alive signal to said integrated terminal controller 
means, said integrated terminal controller means 
comprising means responsive to said periodically 
provided keep alive signal for automaticatly termi- 

25 nating contact with all other keystation means in 
said system for said first keystation means asso- 
ciated with said data input means when said keep 
alive signal periodically provided from said asso- 
ciated data input means is not provided. 

30 In the third aspect of the invention as set out in 

Claim 9, the method may further comprise the step 
of sharing the use of said data input means at said 
given keystation means for inputting said bids and 
said offers associated with said matching transac- 

35 tions and said video conversational textual data 
messages associated with said video conversa- 
tional negotiated trades. Whether it does or not, the 
method may further comprise a step of integrating 
initial access to both said matching trades and said 

40 video conversational negotiated trades in said sep- 
arate networks. Separate networks may be for the 
given keystation means for enabling the given 
keystation means selectively to effect both said 
automatic matching trades and said video con- 

45 versational negotiated trades through said separate 
networks. 

In the third aspect of the invention as set out in 
Claim 9, the method may further comprise a step 
of sharing the use of said data input means for a 

50 given keystation means for selectively providing 
transactional data with respect to both said auto- 
matic matching trades and said video conversa- 
tional negotiated trades to said system. In the third 
or fourth aspects of the invention as set out in 

55 Claims 9 and 10 respectively, the method may 
further comprise a step of retrievably storing com- 
pleted trades from both said automatic matching 
trades and said video conversational negotiated 
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trades together. 

In the fourth aspect of the invention as set out 
in Claim 10, the method may further comprise a 
step of commonly collecting trading ticket informa- 
tion relating to both said automatically matched 
trades for trading instruments traded through said 
first data communication network and said video 
conversational negotiated trades for trading instru- 
ments traded through said second data commu- 
nication network. There may be a further step of 
communication said commonly collected trading 
ticket information to a remote back office data base 
irrespective of the type of trade effectuated through 
said integrated terminal controller. Said commu- 
nicating step may further comprise the step of 
communicating said collected trading ticket infor- 
mation as self-contained integral trading ticket 
records. 

In the fourth aspect of the invention as set out 
in Claim 10, the method may fruther comprise the 
steps of maintaining a host book data base com- 
prising the active bids and offers associated with 
said matching transactions by trading instrument, 
and interfacing said given keystation means with 
said host book data base through said integrated 
terminal controller for effectuating said automati- 
cally provided matching transactions. Whether it 
does or not, the method may further comprise the 
step of processing said matching transactions for a 
given trading instrument in time order entry to said 
first data commnication network, when it does com- 
prise the step of maintaining a host book data 
base, it may further comprise a step of locally 
storing a subset of said host book data base at 
said given keystation means associated with said 
potential matching transactions. It may then com- 
prise a step of providing transaction update broad- 
cast messages to said given keystation means 
through said first data communication network and 
said integrated terminal controller for updating said 
locally stored subsets in accordance with said 
transactional data relating to said automatic match- 
ing transactions. The transaction update broadcast 
message providing step may further comprise the 
step of selectively providing said update messages 
in response to a predetermined condition. The up- 
date message selective providing step may com- 
prise the step of controllably masking the available 
trading market for said automatically matched 
trades at said given keystation means. 

In the fourth aspect of the invention as set out 
in Claim 10, the given keystation means may com- 
prise computer means, said method further com- 
prising the step of periodically providing a keep 
alive signal from said given keystation data input 
means to said given keystation computer means, 
and deleting said bids and offers provided from 
said given keystation means when said keep alive 



signal is not periodically provided from said given 
keystation data input means. The method may then 
further comprise a step automatically terminating 
contact with all other keystation means in said 
5 system for said given keystation means when said 
keep alive signal is not periodically provided from 
said given keystation data input means. 

Clainns 

10 

1. An integrated trading system capable of provid- 
ing both automatic matching trades for trading in- 
struments between potential counterparties at dif- 
ferent locations and video conversational negoti- 

75 ated trades for trading instruments between poten- 
tial counterparties at different locations over a first 
communication means, said automatic matching 
trades comprising trades in which bids from poten- 
tial counterparties are automatically matched 

20 against offers from potential counterparties for giv- 
en trading instruments for automatically providing 
matching transactions in order to complete said 
automatic matching trades for said given instru- 
ments, said video conversational negotiated trades 

25 comprising trades in which video conversational 
textual data messages are selectively routed be- 
tween potential counterparties with respect to bids 
and offers for given trading instruments for en- 
abling discretionary conversational messages to be 

30 exchanged between said potential counterparties in 
order to negotiably completed said video conversa- 
tional negotiated trades, said integrated trading 
system comprising a first plurality of keystation 
means; and a second communication means, said 

35 first plurality of keystation means being selectively 
connectable to said first communication means 
through said second communication means for en- 
abling said first plurality of keystation means to 
selectively communicate with a second plurality of 

40 keystation means at said different locations to ef- 
fectuate said matching trades and said video con- 
versational negotiated trades, at least a first one of 
said keystation means in said first plurality being 
capable of effectuating at least said automatic 

45 matching trades and at least a second one of said 
keystation means in said first plurality being ca- 
pable of effectuating at least said video conversa- 
tional negotiated trades, said first one of said 
keystation means in said first plurality comprising 

50 video display means capable of displaying at least 
said bids and said offers associated with said 
matching transactions and a data input means for 
selectively inputting said bids and said offers to 
said first communication means through said sec- 

55 ond communication means for effectuating said 
automatically provided matching transactions, said 
second one of said keystation means in said first 
plurality comprising video display means capable 
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of displaying said video conversational textual data 
messages associated with said negotiated trades 
and a data input means for selectively inputting 
said video conversational textual data messages to 
said first communication means through said sec- 
ond communication means for effectuating said 
video conversational negotiated trades, said second 
communication means comprising interface means 
connectably disposed between said first one of 
said keystation means in said first plurality and 
said first communication means and said second 
one of said keystation means in said first plurality 
and said first comrnunication means for selectively 
interfacing said first one of said keystation means 
in said first plurality and said second one of said 
keystation means in said first plurality with said 
keystation means in said second plurality through 
said interface means and said first communication 
means: whereby both automatically matched trades 
for said trading instruments and video conversa- 
tional negotiated trades for said trading instruments 
may be conducted through said integrated trading 
system. 

2. An integrated trading system in accordance with 
claim 1 wherein said first communication means 
comprises separate communication paths for said 
matching trades and said video conversational ne- 
gotiated trades. 

3. An integrated trading system in accordance with 
claim 1 wherein said second communication means 
comprises a common communication path for said 
matching trades and said video conversational ne- 
gotiated trades. 

4. An integrated trading system in accordance with 
claim 3 wherein said second communication means 
common communication path comprises a local 
area network means. 

5. An integrated trading system in accordance with 
claim 1 wherein at least said video display means 
for said first one of said keystation means in said 
first plurality further comprises means capable of 
displaying said video conversational textual data 
messages associated with said negotiated trades 
for effectuating said matching trades. 

6. An integrated trading system in accordance with 
claim 5 wherein said first communication means 
comprises separate communication paths for said 
matching trades and said video conversational ne- 
gotiated trades. 

7. An integrated trading, system in accordance with 
claim 5 wherein at least said data input means for 
said first one of said keystation means in said first 
plurality comprises a common data input means for 
selectively inputting both said video conversational 
textual data messages to said first communication 
means through said second communication means 
for effectuating said video conversational negoti- 
ated trades and said bids and said offers to said 



first communication means through said second 
communication means for effectuating said auto- 
matically provided matching transactions. 

8. An integrated trading system capable of selec- 
5 tively providing both automatic matching trades for 

trading instruments between potential counterpar- 
ties and video conversational negotiated trades for 
trading instruments between potential counterpar- 
ties over a data communication network, said auto- 

10 matic matching trades comprising trades in which 
bids from potential counterparties are automatically 
matched against offers from potential counterpar- 
ties for given trading instruments for automatically 
providing matching transactions in order to com- 

75 plete said automatic matching trades for said given 
instruments, said video conversational negotiated 
trades comprising trades in which video conversa- 
tional textual data messages are selectively routed 
between potential counterparties with respect to 

20 bids and offers for given trading instruments for 
enabling discretionary conversational messages to 
be exchanged between said potential counterpar- 
ties in order to negotiabiy complete said video 
conversational negotiated trades, said integrated 

25 trading system comprising at least a first keystation 
means selectively connectable to a plurality of oth- 
er keystation means through said data communica- 
tion network for enabling said first keystation 
means to selectively communicate with said other 

30 keystation means to effectuate said matching 
trades and said video conversational negotiated 
trades; and integrated terminal controller means 
connectably disposed between said, first keystation 
means and said data communication network for 

35 selectively interfacing said first keystation means 
with said data communication network, said first 
keystation means comprising a common video dis- 
play means capable of displaying both said bids 
and said offers associated with said matching 

40 transactions and said video conversational textual 
data messages associated with said negotiated 
trades, and a common data input means for selec- 
tively inputting both said video conversational tex- 
tual data messages to said data communication 

45 network through said integrated terminal controller 
means for effectuating said video conversational 
negotiated trades and said bids and said offers to 
said data communication network through said in- 
tegrated terminal controller means for effectuating 

50 said automatically provided matching transactions: 
whereby both automatically provided matched 
trades for said trading instruments and video con- 
versational negotiated trades for said trading instru- 
ments may be selectively conducted over said 

55 integrated trading system. 

9. An integrated trading system method for provid- 
ing both automatic matching trades for trading in- 
struments between potential counterparties and 
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video conversational negotiated trades for trading 
instruments between potential counterparties over 
separate networks relating to said automatic match- 
ing trades and said video conversational negotiated 
trades, each of said rietworks comprising a plurality 5 
of keystation means selectively connectable to 
each other through said separate network, said 
keystation means comprising data input means and 
video display means; said method comprising the 
steps of sharing use of said video display means io 
for a given keystation means for enabling said 
given keystation means to transact both said auto- 
matic matching trades, in which bids from potential 
counterparties are automatically matched against 
offers from potential counterparties for given trad-. 75 
ing instruments for automatically providing match- 
ing transactions in order to complete said auto- 
matic matching trades for said given trading instru- 
ments, and said video conversational negotiated 
trades, in which video conversational textual data 20 
messages are selectively routed between potential 
counterparties with respect to bids and offers for 
given trading instruments for exchanging discre- 
tionary conversational messages between said po- 
tential counterparties for negotiably completing said 25 
video conversational negotiated trades; and selec- 
tively interfacing said given keystation means with 
both of said separate networks for selectively con- 
necting said given keystation means to keystation 
means in both of said separate networks for en- 30 
abling said given keystation means to selectively 
transact both said automatic matching trades and 
said video conversational negotiated trades through 
said, separate networks; whereby both said auto- 
matically provided matching trades and said video 35 
conversational negotiated trades may be conducted 
at said given keystation means for trading desired 
trading instruments irrespective of the type of 
trade. 

10. An integrated trading system method for pro- 40 
viding both automatic matching trades for trading 
instruments between potential counterparties over a 
first data communication network to a plurality of 
keystation means selectively connectable to each 
other through said first data communication net- 45 
work and video conversational negotiated trades for 
trading instruments between potential counterpar- 
ties over a second data communication network to 
a plurality of keystation means selectively connec- 
table to each other through said second data com- 50 
munication network, said keystation means com- 
prising data input means and video display means, 
said keystation means being selectively connec- 
table to both said first and second data commu- 
nication networks through interface means for se- 55 
lectively interfacing said keystation means with 
each other through said first and second data com- 
munication networks, said method comprising the 



step of providing transactional data between said 
keystation means and said potential counterparties 
relating to both said automatic matching transac- 
tions and said video conversational negotiated 
trades through a common integrated terminal con- 
troller means for enabling a given keystation means 
to selectively effectuate both said automatic match- 
ing transactions and said video conversational ne- 
gotiated trades through said common integrated 
terminal controller to said first and second data 
communication networks, respectively. 
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•include <stdio.h) 
•ioclud* <und«f.h> 
•unde/ >*OmEmmGR 
•undef nOwInmESSACCS 

• include <wincjow».h> 
•include **3m»g.h* 
•include "a3ctrl.h" 

• include "*dartif.h" 

• Include ''dlalogid.h * 
•include "pwt Icgn.H" 
•include "rdii_di I .h" 
•include "rdis^clL.n" 
•include "a3netlib.h" 
•include *fatAl.h' 



typedef enum 
{ 

OART. 
ROTS 
) APPLICATION; 
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TABLE A 



typedef enum 
{ 

S^QUERYSENT . 

s^querywait . 
s'logoffsent, 
s\0g0ffwatt» 
s"loggeooff. 



s_oartloggingon , 

S~ROTSL0GGiNGON. 
S_ACTIVE, 
S^OARTACTIVE. 
S'iNHlBITEO. 
SJNACTIVE 
) ROr STATES; 



> se«t a ROIS_OUERVlOGOFF and am waiting for a r«pty •/ 
nave cct a flcTs_QLReS0NSE and waiting for otner •/ 
have se"^ a ROIS_LOGOFr to both parties •/ 
wa'^i.-c for. trie otner partie to reply •/ 
Oct- cirties are logged off •/ 

*a': for C4RT to Logon •/ 
fo' ^OTS to logon •/ 
oct- :;a'fes are logged on and active •/ 
oa-t --ly IS active •/ 
-e^'. i*----^ inhibited •/ 
= ; -i tirsg for otalog data •/ 



/• ROI states •/ 
ROI^STATES state = S 



/• used for debugging •/ 
•if defined (OEBUG) 

cnar -pState fj = { ' SJivZ^'^SlN: . s_QuERywa i T" . 

•S^R0TS-CGG;.n3Cn . SACTIVE" 

•endif 



■S_tOGOFF5£!HT- . 
■i DARTACTIVE- 



■S LOGOFFWAIT- 
"S INHI8ITE0- 



-S tOGGEOOPF-. 
-s'lNACTlVE-}; 



*S OARTlOGGInGCn 



/• deDug macros 

•define tlT(s) •* 

•define LlT£RAt(n) Ll^Cn; 
•define WngSE fli-E 

static HWNO h^ncjOialog - 
static iCGCN^CArA Logor-Cata = 
static long Logoff Reason z q 



.*o).(a}.{o;.{o}.{o)); 



/ • max 1 mu-Ti li.Tiit if TOs 
•define max^CaRTIO 5;: 

■define >iax_r::ts:o :zz2 

/• Id's sent out to apps •/ 
static wORO Oartid = 0; 
static WORD Ratsid - 0; 



static vo*d uOCAu SetRO:S:ite . : _^ * -i * ES s); 
static void uOCAL TeUROTSLogcn : , z-g .=>aram) ; 
static void EnoiogonOi alcg (vo'-C, . 
static WORD LOCAL 3etNewId (APOL:Ci*:CN *pD) . 
static void LOCAL SenoLogcff (ic-a ;-5»ason). 



...••»...•/ 

/« Module : roilogon.c •/ 

/• Routine; void LOCAL CialogOata ;"*»*0'_c rwem) •/ 

/• tms procedure is sent t**e logon data from setup ana t^en •/ 

/• starts tne loocn process -»tn OART and ROTS */ 

/•Return ; •/ 

/• •/ 
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/....«.......,.......,................•«. / 

void LOCAL OlalogOttA (HANOtE hM^fn) 

( 

tPLCXjC»<_OATA Ip . (LPLOGOM_^OATA) Glob*lLock (hHem); 
LO9On0«t« * *lp; 
GlobalUniock (hMM) ; 

/• long parameter i» Handle :of fact , i am roc going to '^eea an offset 
• at the moment so offset is zero 
•/ 

/• s«t flag to tell myself that /"eply will be from Oa^T as . tne oa^t 
. « logs on before ROTS 
•/ 

SetftOIState (S^OAWTLCXIGINGOn) ; 

/• check result frofli logon message •/ 

switch {(WOf^O) CtrlSendHessage (mOO CART, ROIS LOGON, 0. MAKtLCsG (0, r>4efn))) 
{ 

/• Can't log on because printers have failed •/ 
cas« LO_PRINTERSfAlLE0: 

SetftOIState (S_LOGGEDOPF) ; 

CtrlSendMessage (MOO SETuP. DM ERRORTExTOlALOG . hwnoOiaLog. CLoog) tc PRINTERS FAILED); 
break; 

/• Can't log on since ROTS is present and 

« th« ROTS trada printer is not installed •/ 
cas« LO_PRINTERNOT INSTALLED: 
SetROIState (S^LOGGEDOFF ) ; 

CtrlSendHessage (mOO^SETup, Om £RR0RT£XT0IAl0G . r'WndOialog, (long) TC nO RQTS PRINTER); 
break; 

case L0_0K: 
break; 

case LO^BADOATA: 

OartFatalExit (rrL_BAO_^C:.CN_OArA ) ; 
break; 

case LO_ALREAOYON: 

OartFatalExit (FTL^alREa^v On ) ; 
break; 

default: 

OartFatalExit (FTL SAO RE^LV). 
breik; ~ " - 

} 

) 



/••••««•«•«•«•««•«•«•.••«..•••.•.•,...•.,.,...,,«...,, .../ 

/• Module : rdllogon.c •/ 

/• Routine: void LOCAL Oi alognandi e (hwnO hwrxj) •/ 

/• gets the handle to t-e analog disolayea by sctus. mis "a-c^e •/ 
/• is then used to pass -essages tc ^r.p c.A^.og, e s'-c messo=es 

/• Return : void •/ 

/• ./ 

/«,«.....«««...„.••.••,..... 



void LOCAL Olaloghandle (hwno r«-a; 
{ 

hwnd Dialog = hWnd; 

} 



/,•,.«..«•* •....•••...«...... / 

/■ Module : rdilogon.c •/ 
/• Routine: static void EndLogonC* aiog (void) •/ 
/• sends a message to tf^e setwp modw.e to eno t^e -.ccon dialog •/ 

/• . ' •/ 

/• Return : void •/ 
/« . ./ 

/••••««....,..«.,..•..•••..,,.. / 

static void EndLogonOialog (void) 
( 

CtrlSendHessage (hOO^SETuP, Om_£s;; : 4(.oG . "--kjOi alcg. . OL ) ; 

/••••••••••••••••'«••• • / 

/• Module : rdHogon.c •/ 
/• Routine: static WORD LOCAL GetNe-ld (APPLICATION App) •/ 
/* allocates a new id for POTS or CART «/ 

/• •/ 
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/• Peturn : new lO 



%zityc itCRO LOCAL GecNewla (APPLICATION Apo) 

{ 

5t*ttc *<0«0 OartIO = 0; 

static wO«0 nOTSIO = KAX_CARTIO ♦ 1: 

switcn (Apo) 
{ 

case DART; 

/■ tncrement counter and cneck for roU over •/ 
DactIO**; 

if (OartlO >= hax^CaRTID) 

OartIO =0; 
tSf defined (DEBUG) 

pr intf { 'Cart id = Xd\n" , OartIO) ; 
iendif 

return OartIO: 
case ROTS: 

/• Increment counter and check for roll over •/ 
ROTSIO**: 

if (ROTSIO >= MAX_ftOTSIO) 

ROTSIO = MAX_OARTID ♦ I; 
•if defined (OESuG) 

printfC"ROTS id s Xd\n" . ROTSIO); 
«endif 

return ROTSID; 

ccf auL t : 

PatalEjiit ( Ptl_ihcCRR£CT *pP) ; 
break; 

) 

) 



/ 



/• Module : rdUogon.c ,y 

/• Routine: void LOCAL KeySoa^c2e'-acne<J (void) •/ 

^* called when tr.e vevocard is detached, and then takes action •/ 

/• according to ROl scec ./ 

/• Return : void 



void LOCAL KeyBoaraOetacned (void) 
( 

■if defined (OEBuG) 

pr tntf ( "OM^KaOOETACHXn" ) ; 
• e-xaif 

switcn (state) 
< 

case S_lNACTIve : 
case S'OARTACTIVE: 
case s\oCGeO0FP: 
case S^OuERYSEnT: 
case S^OUERYWAIT: 
case s'lOGOFFSEnT: 
case S^lOGOFFWaIT : 
case S~ACTIVE: 
case S^OaRTlOGGInGOn: 
case S^^'OTSlCGGInCON; 

SetROIState ( S_lOGOFFSEst ) ; 

SendLogoff ((long) lF_D£^aCh)- 

oreak ; 



} 



) 



/• Module ; (-di logon. c ./ 

/• Routine: void LOCAL Key BoardSt a- e ( -OPO HeySoardState) •/ 

^* called when the keybcaro s^ate cnanges and then ta«es action •/ 

/• according to ROl spec •/ 



/• Return 



void LOCAL KeyBoardState (WORD KeySoaroState) 

•if defined (OEBUG) 

printf ("OM^KBOSTATE %a\n' , <ey8o«roState ) ; 
•endif 
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/• if string not ther« or set to I then process message •/ 
if (G«tProfii«Int (-ART3-. "KecDAliv*-. I) =. Q) 

•tf defined (OesuG) 

pr intf ( Mgnore kceo «Live\n"); 
•end! f 
''•turn; 

) 

switch (state) 
{ 

case 5_lNACTlve: 
cas« S_0ARTAC7rVc: 
case S~LOGGecX)FF : 
case S^OUERVSEMT: 
case S'OUERYWAU: 
case s'lOGOFFSENT: 
case S_LOGOFFVAIT: 
case S^ACTIVE: 
case S^OARTloGGInGOn: 
case S_flOTSL0GGlNCON: 

SetROIStete (S_LOGOFFSEnt ) ; 

if CKey8oarcJState == 0) 

logoff Reason s lF OOFaIL; 

else ~ 

Logoff Reason = lP_K80CK; 

•if defined (OESUG) 

printf (-tceytsoarcj state = XdNn" , Logoff Reason) ; 



SendLogoff (LogoffReasc- . 
break; 

) 

) 



/• Module : rdUogon.c •••♦•••«•••••«•«•••..•...•.••/ 

/■ Routine: void LOCAL ROIS.c^.c.y (mwno hWr<.. WORD nResuLt, Long LParam) !/ 

U t^"^ !Srr? messages, if fr^ dart arxi is success ./ 

' t^en ROTS logs c--^ 

/• Return .void *' 

/. •/ 

/•...... . 

void LOCAL ROISLoRepiy (HWNO ---^d . WORD nResut J! ' [o^"pIrliir ^ 

•if defined (DEBUG) 

printf ( ■•ROIS_LO_REPLV\n ' ] ; 
• end if 

s%*itcn (state) 
( 

case S_0A«TL0GGING0N: 

/• first cneck res-ji'- c' logon •/ 

switcn (nflesult) 

( 

case lO^O«: 

SetROIState (SJROXSlZZZIsOOh); 
Tel IROTSLogon TlPari-, 
break; 



case LO_REjECT£0: 

/• logon nas failed %z 90 oack to logged of status •/ 
SetROIState ( S^lCGG£OC=F ) . 

CtrlSenOMcssag; ( nOO,S-: XP . 0M_ERRORT£XT0I ALOG , hWndOialog. (long) TC_9A0_0LR_1 0) ; 



case LO^alREaOYOn: 

SetROIState ( S_LCGGEOC- ? ) ; 

CtriSendMessagi (hOO.S£-„p. CM_e9RORTExT0lAL0G.. hWndOialog. (long) TC_OlR_ON^TWICE) ; 

) 

break; 



/• dont remove dialog as its not cn i^apiaV •/ 
case S^OARTACTIVE: 

/• first Check result of logon •/ 

Switch (nPesult) 

( 

case LO_N0NTflAOlNG : 
case LO^LINEDOWN: 
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/• «OTS reoorts i i a© ao^n tx.t OaRT can carry on •/ 
• if <3«finea (0€3UC) 

printfCROTS Hnedown\n-); 
■•ndif 

SetROIState (S OAflTACTlvE); 

cas« LO_OK: 

SetROIState (S ACTIVE); 
•if defineo (OEBUG) 

printfCROI: EveryoocJy logged on an<j happy !...\n-). 

.break; 

case tO^BAO^TfUOER: 
break; 

case LO^INMIBI TEO; 

/.^cant display a ^^ssage as logon box is not displayed •/ 

case LO_LOG0FF: 
case C0~REJ6CT£D: 
break; 

} 

break; 

case S_R0TSL0GGING0N: 

/■ first checit result of logon •/ 

switcn (nPesult) 

( 

case LO^nOntraoING; 
case t.o\lNE0OWN: 

/• ROTS reports l-e cc-n CART can carry on ./ 

•if defined (CESuG) 

prtntf ("ROTS I i =c.n\n-); 

•endif 

SetROlState (S_CaR7ac : : .£ ) ; 
EndtogonOialog'o ; 

CtrlSendMessage r-CC_:^^r. ROIS AlllOGGEOOn. 0 OL)- 
break; " . . u»./, 

case LO_OK; 

SetROIState (S^aCtivE). 
EndLO9an0ialo9~( ) : 

CtriSendMessage (hO0,3-PT. c^qIS aullOGGEOON , 0. OL) • 
oSI!!*'^"""^* (r'-ncQOTS. =»OIs"ALLLOGCeOON . 0, OL) ' 

:?j'd:M::r:?E8i;r''''* --^^^^-^^"^.switch. Rois^Acnv.TE.ROTs. od; 

• en^ir^^^^°^' Everybody logged on and happy i!;!\n-); 
break ; 

case LO_aAO_r^AOER: 

SetwBlState {S_LCGGtOO?P) ; 
Oartid s G«tNe^Id ICaRT);' 

CtriSendMessage i-00_CAR;. ROtS_LCGOfF. Oartid. (long) lF USER)- 

break; 

case L0_[NHr8irEC: 

/• log OART tac« off • 
SetROIState ( S_LCGGc30r = ) . 
Oartid = GetNe-Id (Cartj ; " 

rr.i*2^;!""^* (h00.Ca;5T. ROIS_lOGOFF. Oartid. (long) LF USER); 

CtriSendMessage (K^O.SET.P. Cm,errORTEXTOIauOG . nWr<,01aipg. (long, TC.RDTS Jnh IBITEO) ; 
case LO_LO(iOFF: 

cMS?^? ''^ ^ -^'^'^ ^^^9ed of status •/ . - . 

SetROIState ( S aOGGEDCFF ) . ' 

Oartid = GetNewid (OART; 

CtrtS.ncM.„.,. (HO0.0*«t. ,q: S...OOOFr . C.rtlO. (long, LF_USER): 
case LO REJECTED: 

Oartid = GetNewId (CART); 

CtriSendMessage (h0O_OarT . ROIS^LCGOFF. Oartid. (long) LF USER) ' 

CtrtSendMessage (H30.SETUP. Ch.ERRORTExtoia.oG ! hw^ialog tlo;>g) TC.BaO,PaSSWORO) ; 
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SetROtStat« (S^LOGGEOOFF) ; 



CtrlS«ndMcss*g. {hOO_5ETuP. Oh_ERPO«T£XTOIALOG . hWndOiaiog. (Long) TC 0L« ON TWICE) 



> 

break: 



> 



•/ 
•/ 



7 



/• Hcxiule : rdi logon , c 

/• Routln«: void LOCAL ROISLcggecOf f (mwnO hWnd . wOflO -Id) 

^* nandles th« ROIS LCGGEO OFp meisaqei 

/• - _ 3 •/ 

' /• Return : void *^ 

/.•..••.•.,•., 

void LOCAL ROISLoggedOf f (mwnq nw<^<l , wORO wid) 

•if defined (OESUG) 

pri ntf ( -ROrS_^LOGGEO OFF\n" ) ; 
•endif 

switch (state) 
( 

case S^OARTaCTIvE: 

•if defined (DEBUG) 

pr1ntf(-line down aro '<z\% Icqgec off\n")- 
ieryjlf ' 

break; 

case S^LOCGEOOFF: 
case S^ACTIVE: 

/• if in this state tn*^ .-.coff has been aborted •/ 

break; 

/• first reply from someone • 
case S^LOGOFFSENT : 

if Twid =r Oartid II -!:: -riX'&W 
SetROIState ( S_LCCOr- : ' , 

break; 

/• second reply therefore pcc cialog •/ 
case S^LOGOFFWAIT : 

SetROIState (S_LOCG£OOFF j . 

w T^^J^"^ OeSugging snouLd not be send unless both parties aggree •/ 
If (RDTSPresentl 



} 



f (RDTSPresent) 

CtriPostMessage (mOC_SETuP. Om^STaRTQIalOG, hWnd. makELCnG (SO.LOGON, 0)); 

breakP'^'''''""^* (hQO.SETuP. Oh_ST aRTOI alOG . hWnd. makELCnQ (SO.CHANGE.OEALER. 0)): 
> 



else 



•/ 
•/ 



/..«•«......«..,,. 

/» Module : rdVlogon.h 

/• Routine: void LOCal ROISlooc* * ^-;.es t (hwnO hWnd) 
^' processes a request ' -l^. CaRT or RQTS to log off 

/■ Return : void 

' ■ • 

void LOCAL ROISLogof fRcQuest f.o-q =ea5on) 

•If defined (DEBUG) 

printf ( -ROIS LOGOFFR£0u£ST\n \ 
•endif 

/. If -e have received a Om_ST^;;t message and one or other of the events 
•^have happened then -e can start ,n:t,ai logon sequence 

if (GotOMStart (RegTimerCxpi-ea :; ROTSP-esent ) ) 

switch ((WORO) Reason) 
{ 

case LF_STARTuP: 

/• starting up so force logoff •/ 
/• save reason for logoff message •/ 
SetROIState (S^LOGOFFSENT ) ; 



34 



EP 0 434 224 A2 



S«n(3L090f f C Reason ) ; 
break; 



default: 

/• 9av« re«aor> for logoff (neasage •/ 
Logoff Reason = Reason; 

SetflOIState (S_OUEnYS£Nr) ; 

/• post messages to OART ano ROTS reouesting that they log off •/ 
Oartid = GetNewld (OaRT); 

CtrlPostMessage (K30_C*RT. ROIS^OUERYLOGOFP . Oartid, OL) ; 

. /• ff^JSt n*ake sure tnat c^e post gets througri •/ 
Rdtsid = GetNe**Ia (RCTS): 

*-hUe (PostHessage (ft-'^cSDrs. ROIS OuCRylOGOFP, fldtsld. OL) 0) 
printf{WMeRE "ROI =^stMessage faUedNn"); 

break; 

) 

} 

) 



/• 

/• Module : rdi logon, c 



/« Routine: void LOCAL ROlSOl r esonse (hwnO hwno, WORD -Id, WORO oResult) •/ 
/• handles R0IS_0LRe5PCNS£ message ./ 

^* •/ 
/• Return : 

/ 



void LOCAL ROISOlresonse (hwnO -wc. -ORO wld. wORD nResult) 

•If defined (OGBuG) 

printf ( •*ROIS_OLR£SPCnSE - . 
•endif 

switcn (state) 
( 

case S^LOGGEOOPF: 
case S^ACTIvE: 

/• if in this state i-c- : - .ogoff has seen aborted •/ 

break; 



case S QUERYSENT: 
{ 

/• check result of izqz- ' »--3uiry •/ 

switch (nResult) 

{ 

case OL_STCP: 

SetAOIState (S_ACTive): 

/• tell setup tf^at fe logoff nas been aborted •/ 
ClrlScnOMcssage (mCO_S£TuP. Om ExTRn OIalOG ABORTED 0 Ot)' 
break; ~ ~ . ' 



case Ol__aCTIvE: 

/• abort logoff a-^ sec ^CI state back S ACTIVE •/ 

SetROIState (S^aCTIv?). 

if (wid == Oartlo 1; -1:3 - - =»otsId) 

CtriPostMessace C >''0_S£ * JP . Om_st aRTOI alOG, hwod . ma-^ElOnG (SO aCTIvE CONVS, 0)) 
break; 



case OL_OK: 

if-(wld =•= Oartic j- z =ctsld) 

SetRCIStace .S C. £--..-:■:. 
break; 

) 

} 

break; 

/• wait for the otner pai-ty to '-oiy •/ 
case S_QU£RYWAIT: 

switch (nPesult) 

( 

case QL_STOP: 

SetROIState (S_ACTlv£). 

/• tell setup tnat the lo?o" -as oeen aoorted •/ 
CtrlSendMessage (HO0_S£*i-P. =*rqN OMlOG aBORTEO. 0. OL): 
break; 

case 0L_ACTIVE; 

/• abort logoff and set RO! state bacH S ACTIVE •/ 

SetROIState (S ACUVE); 

if (wId == Oartid II wid == Sotsld) 

CtrlPostMessage (mO0_S£TuP. 0M_STARTOtALOG, hWno .MAKElONG (SO ACTIVE COmvS, 0)) 
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break; 



C4s« QL OK: 

{ 

/• requ«it from ROTS to remov. the are you sure di*l 
• tXit 1 will leav* th« coo« in case tncir m^nQs 
« ara changed 
•/ 

• If 0 

WORD result; 



«eisa 



«endif 



SetPOIState (S^Inact :ve ) ; 

•result = (WOROT Ctr-Ser^CHessace (hO0_S£TuP. CH_STAflTOI acOG . r.Wnd. hakELOnG (SO.AREYOUSURE. 0)); 
/• If USar says yes tnen fimsn logoff •/ 

if (result s= lOYES) 
{ 

SatflDIStata C5_L0GCPFSEnt ) . 
SandLogoff (Loiof f Peason ) 
break; 

) 

/• tf ro then go oack to active •/ 
»lsa If (result == lONO) 
SetROIState (S_aCTIvE); 

/• If result is something different then <3o nothing •/ 
break; ^ ' 

/« do It the old wav •/ 
SetROIState {S^LOGOPrsEs: ) ; 
SendLogoff (Logof fReasor; . 
break; 



) 
} 

break; 



dafault: 
break; 

) 

} 

/• Module : rdUogon.c «■••■••••••••••••«.••«•••/ 

/• Routine: void LOCAt ROISStatus (M^RQ -eason) ]y 
processes the ROIS^STiruS message 

/• Return : void *^ 
/• •/ 

/...•.•.,...„........,... ^ ^ •/ 

void LOCAL RDISStatus (WORD ^easor* •••••••.•.«...-.•..---.....,.».,/ 

{ 

•If defined (DEBUG) 

pr1ntf(-RS STATUS Xd\n\ reason) 
•erejlf 



switch (state) 

( 

case S_lMACTlve; 
case S^OARTACTIVE: 
case S^OUERYSeNT: 
case S^OUERYWAtT: 
case S~LOGOFFSENT: 
case S_LOGOFFVAIT: 
case S~ACTIVE: 
case S^OARTLOGGINGON: 
case S^flOTSLOGGINGON: 

switch (reason) 

{ 

/• handle as if detachco has cee^ 3etecteo •/ 
case RS_ImP£RativE: 

SetROIState (S^LOGOFFSEnM . 

SendLogoff ((long) lF lMP£9i.:-,r) 

break; 

case RS_01SC0nnECT : 

KeyBoardDetached ( ) ; 
break; 



case RS^HOST SHUT DOWN: 
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} 



) 



SctROIStat* (S_OARTACTIVE) ; 
Rdtsid s GetN«^ld (ROTS); 

ROISSendMessage {hWneJftOTS. R01S_L0G0FF, Rdtsld, (lQn9)LF M0STSHuTtX3WN) 
break; 

case RS_MOSTL0G0FF: 

Set«OIStat« (S^OARTACTIVE); 
Rdtald = GetN«wId (ROTS); 

ROISSendHessag* (hWndROTS. ROIS^LOGOFF, Rdtald, (long)LF hOSTlOGOFF) 
break; 

case RS_LINEOOWN: 

.SetROIStata (S_OARTACTlvE) ; 
Rdtsid = GetNewId (ROTS); 

R0I5SendM«ssag« (hWryjROTS, R0IS_LOG0FF, fldtsid, (long)LF LInEOOwn)- 
break; ~ - • 

case ftS_LlN£UP: 

/• 1 wiU set the state but if Itne is cormiing up ther 
• dart only is running and ^ should already be \n this state 
•/ 

SetROIState (S_OARTACT IVE) ; 
TellRDTSLogon (Ot); 
break; 



case RS_UNINHIBIT: 

/• 1 understand that this cant happen •/ 
break; 

) 

break; 



/• HcxJule : rdi logon. c 

/« Routine: static void LOCal Se'.RDIState (RDI_STATES s) ./ 



/• sets the state of tt-e logon code 

/• 

/• Return : void 
/• 

/•••••..••••,.«.«.«,..,.,.«......«,^,,,,,« 

static void tOCAL SetROIState (ROI STATES s) 
( 

•if defined (DEBUG) 

printf ("State Xs -> Xs\n ' , pState(st*te) . pState{s3); 
•enoif 
state as; 

> 



•/ 

•/ 



/• 
/• 
/• 
/• 
/• 
/• 
/• 
/• 

St 

( 



Module : roi logon. c 

Routine: static void LOCAL SendLogoff (long IResson) 
sends a logoff request to ROTS and DART 

Return : void 



atic void LOCAL SendLogoff (Long iReason) 



Logoff Reason = IReason; 
Cartld = GetNewId (CART); 
CtrlSefKJMessage (mOO_DART . 
Rdtsld ~ GetNewId (ROTS); 
ROlSSendHessage (hWndROTS, 



?'0IS_L0GOFF, Oartld. Logoff Reason ) ; 
R0IS_LOGOFF, Rdtsld, Logoff Reason) ; 



/• HoduLe : rdi logon. c 



•/ 

/• Routine: static void LOCAL Te u^lDTSLogon (long IParam) •/ 
/• copies data from OART logon and instructs ROTS to logon •/ 



/• 



/• Return : 



static void LOCAL Tel IROTSLogon (long v'^a'-am) 
( 

/• log on is required so copy data and send a message to setup •/ 
HamOlE hROIcopy = MlwORO (IParam); 
int offset = LOWORD (lPar*m); 
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HANDLE MHycooy: 
LPLOGONOATA ipMycooy; 
LPtOGOW~OATA lp«OIcooy; 
WORD L090ASourc«; 

hMycoDy s GlobAlAUoc (GHNO 1 GMEM^SMARE, (long) sizeof (LOGON OATA)); 
IP_FAlL£0_exiT(hMycopy, PTL_MO_lOGON_mEM ) ; 
IpMycoDy s (LPLOGCN OATA) Glob*lLock"(hHycopy) ; 
rF_FAlL£0_EXlT ClpMycogy. PTL_NULL_P0INTER) ; 



switch (state) 

case S «0TSL0GGIN00N: 
{ 

IpROIcopy = (LPLCGON OATA) GlobalLock (hROIcopy); 
IF_FArLED_EXIT (LoftOIcODy. PTi._NULL_POrNTER) ; 

/• now »Uow for offset if there is any. blame the designer for alL this 
• *f*jcWing aoout «itn offsets 
•/ 

LpROIcopy = (LPLOGON^OATA) ((LPSTR) l pWOIcopy . ♦ of f set ) ; 

/• make a copy of t^e oata •/ 
•IpHycopy - •ipftOIcopy; 
LogonOata = «lpROIcopv; 

/• set packet markers •/ 
lpHycOpy->stJC - STX; 
lpMycopy->etx = £TX; 

/• togon from oialog Dox •/ 
LogonSource = LG^OSOX ; 
GVobaVUnlock (hPOIcopy); 
break; 



case S OARTACTIVC: 
{ 

/• make a copy cf the ca-a ^ recived at the last logon */ 
•LpMycopy = LogonOata; 

/• set packet marners */ 

lpHyCOPy->Stx = STX ; 
lpMycopy->ct« = E7X; 
/• logon from lineup •/ 
LogonSoorce = lG^auTO; 
break; 

} 
) 

GLobalUniock {hMyco=y); 

sw>tch (f^ORO) ROlSSenOMessage (hWrxjROTS. ROIS^LOGON, LogonSource^ MAKELOnG (0. hMycopy)) 

case l0_OK: 
brean; 

case L0_8AOOATA: 

OartFatalExit ( FTL_a*0_LCGON DATA); 
break; 

case L0_ALREADVOs: 

Oartf atai E« i c i P',_alR£aC CnJ ; 
break; 

default: 

OartFatalExit ( FTL_9aO R£=LV ) , 
break; 

) 

GtobalFree (hMycopy); 
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